Index pour requête SQL avec condition WHERE et GROUP BY

J'essaie de déterminer quels index utiliser pour une requête SQL avec une WHEREcondition et GROUP BYqui fonctionne actuellement très lentement.

Ma requête:

SELECT group_id
FROM counter
WHERE ts between timestamp '2014-03-02 00:00:00.0' and timestamp '2014-03-05 12:00:00.0'
GROUP BY group_id

Le tableau compte actuellement 32 000 000 lignes. Le temps d'exécution de la requête augmente beaucoup lorsque j'augmente le délai.

Le tableau en question ressemble à ceci:

CREATE TABLE counter (
    id bigserial PRIMARY KEY
  , ts timestamp NOT NULL
  , group_id bigint NOT NULL
);

J'ai actuellement les index suivants, mais les performances sont encore lentes:

CREATE INDEX ts_index
  ON counter
  USING btree
  (ts);

CREATE INDEX group_id_index
  ON counter
  USING btree
  (group_id);

CREATE INDEX comp_1_index
  ON counter
  USING btree
  (ts, group_id);

CREATE INDEX comp_2_index
  ON counter
  USING btree
  (group_id, ts);

L'exécution d'EXPLAIN sur la requête donne le résultat suivant:

"QUERY PLAN"
"HashAggregate  (cost=467958.16..467958.17 rows=1 width=4)"
"  ->  Index Scan using ts_index on counter  (cost=0.56..467470.93 rows=194892 width=4)"
"        Index Cond: ((ts >= '2014-02-26 00:00:00'::timestamp without time zone) AND (ts <= '2014-02-27 23:59:00'::timestamp without time zone))"

SQL Fiddle avec des exemples de données: http://sqlfiddle.com/#!15/7492b/1

La question

Les performances de cette requête peuvent-elles être améliorées en ajoutant de meilleurs index, ou dois-je augmenter la puissance de traitement?

Modifier 1

La version 9.3.2 de PostgreSQL est utilisée.

Modifier 2

J'ai essayé la proposition de @Erwin avec EXISTS:

SELECT group_id
FROM   groups g
WHERE  EXISTS (
   SELECT 1
   FROM   counter c
   WHERE  c.group_id = g.group_id
   AND    ts BETWEEN timestamp '2014-03-02 00:00:00'
                 AND timestamp '2014-03-05 12:00:00'
   );

Mais malheureusement, cela n'a pas semblé augmenter les performances. Le plan de requête:

"QUERY PLAN"
"Nested Loop Semi Join  (cost=1607.18..371680.60 rows=113 width=4)"
"  ->  Seq Scan on groups g  (cost=0.00..2.33 rows=133 width=4)"
"  ->  Bitmap Heap Scan on counter c  (cost=1607.18..158895.53 rows=60641 width=4)"
"        Recheck Cond: ((group_id = g.id) AND (ts >= '2014-01-01 00:00:00'::timestamp without time zone) AND (ts <= '2014-03-05 12:00:00'::timestamp without time zone))"
"        ->  Bitmap Index Scan on comp_2_index  (cost=0.00..1592.02 rows=60641 width=0)"
"              Index Cond: ((group_id = g.id) AND (ts >= '2014-01-01 00:00:00'::timestamp without time zone) AND (ts <= '2014-03-05 12:00:00'::timestamp without time zone))"

Modifier 3

Le plan de requête pour la requête LATÉRALE de ypercube:

"QUERY PLAN"
"Nested Loop  (cost=8.98..1200.42 rows=133 width=20)"
"  ->  Seq Scan on groups g  (cost=0.00..2.33 rows=133 width=4)"
"  ->  Result  (cost=8.98..8.99 rows=1 width=0)"
"        One-Time Filter: ($1 IS NOT NULL)"
"        InitPlan 1 (returns $1)"
"          ->  Limit  (cost=0.56..4.49 rows=1 width=8)"
"                ->  Index Only Scan using comp_2_index on counter c  (cost=0.56..1098691.21 rows=279808 width=8)"
"                      Index Cond: ((group_id = $0) AND (ts IS NOT NULL) AND (ts >= '2010-03-02 00:00:00'::timestamp without time zone) AND (ts <= '2014-03-05 12:00:00'::timestamp without time zone))"
"        InitPlan 2 (returns $2)"
"          ->  Limit  (cost=0.56..4.49 rows=1 width=8)"
"                ->  Index Only Scan Backward using comp_2_index on counter c_1  (cost=0.56..1098691.21 rows=279808 width=8)"
"                      Index Cond: ((group_id = $0) AND (ts IS NOT NULL) AND (ts >= '2010-03-02 00:00:00'::timestamp without time zone) AND (ts <= '2014-03-05 12:00:00'::timestamp without time zone))"

Une autre idée, qui utilise également la groupstable et une construction appelée LATERALjoin (pour les fans de SQL-Server, c'est presque identique à OUTER APPLY). Il a l'avantage que les agrégats peuvent être calculés dans la sous-requête:

SELECT group_id, min_ts, max_ts
FROM   groups g,                    -- notice the comma here, is required
  LATERAL 
       ( SELECT MIN(ts) AS min_ts,
                MAX(ts) AS max_ts
         FROM counter c
         WHERE c.group_id = g.group_id
           AND c.ts BETWEEN timestamp '2011-03-02 00:00:00'
                        AND timestamp '2013-03-05 12:00:00'
       ) x 
WHERE min_ts IS NOT NULL ;

Un test sur SQL-Fiddle montre que la requête effectue des analyses d'index sur l' (group_id, ts)index.

Des plans similaires sont produits en utilisant 2 jointures latérales, une pour min et une pour max et également avec 2 sous-requêtes corrélées en ligne. Ils peuvent également être utilisés si vous devez afficher les counterlignes entières en plus des dates min et max:

SELECT group_id, 
       min_ts, min_ts_id, 
       max_ts, max_ts_id 
FROM   groups g
  , LATERAL 
       ( SELECT ts AS min_ts, c.id AS min_ts_id
         FROM counter c
         WHERE c.group_id = g.group_id
           AND c.ts BETWEEN timestamp '2012-03-02 00:00:00'
                        AND timestamp '2014-03-05 12:00:00'
         ORDER BY ts ASC
         LIMIT 1
       ) xmin
  , LATERAL 
       ( SELECT ts AS max_ts, c.id AS max_ts_id
         FROM counter c
         WHERE c.group_id = g.group_id
           AND c.ts BETWEEN timestamp '2012-03-02 00:00:00'
                        AND timestamp '2014-03-05 12:00:00'
         ORDER BY ts DESC 
         LIMIT 1
       ) xmax
WHERE min_ts IS NOT NULL ;

Puisque vous n'avez aucun agrégat dans la liste de sélection, le group byest à peu près la même chose que de mettre un distinctdans la liste de sélection, non?

Si c'est ce que vous voulez, vous pourriez obtenir une recherche d'index rapide sur comp_2_index en réécrivant ceci pour utiliser une requête récursive, comme décrit sur le wiki PostgreSQL .

Créez une vue pour renvoyer efficacement les group_ids distincts:

create or replace view groups as
WITH RECURSIVE t AS (
             SELECT min(counter.group_id) AS group_id
               FROM counter
    UNION ALL
             SELECT ( SELECT min(counter.group_id) AS min
                       FROM counter
                      WHERE counter.group_id > t.group_id) AS min
               FROM t
              WHERE t.group_id IS NOT NULL
    )
     SELECT t.group_id
       FROM t
      WHERE t.group_id IS NOT NULL
UNION ALL
     SELECT NULL::bigint AS col
      WHERE (EXISTS ( SELECT counter.id,
                counter.ts,
                counter.group_id
               FROM counter
              WHERE counter.group_id IS NULL));

Et puis utilisez cette vue à la place de la table de recherche dans la existssemi-jointure d' Erwin .

Puisqu'il n'y en a que 133 different group_id's, vous pouvez utiliser integer(ou même smallint) pour le group_id. Cependant, cela ne vous rapportera pas grand-chose, car le remplissage à 8 octets mangera le reste de votre table et les index multicolonnes possibles. Le traitement de plain integerdevrait cependant être un peu plus rapide. Plus sur le sujet intcontreint2 .

CREATE TABLE counter (
    id bigserial PRIMARY KEY
  , ts timestamp NOT NULL
  , group_id int NOT NULL
);

@Leo: les horodatages sont stockés sous forme d'entiers de 8 octets dans les installations modernes et peuvent être traités parfaitement rapidement. Détails.

@ypercube: L'index sur (group_id, ts)ne peut pas aider, car il n'y a aucune condition group_iddans la requête.

Votre problème principal est la quantité massive de données à traiter:

Scan d'index en utilisant ts_index sur le compteur (coût = 0,56..467470,93 lignes = 194892 largeur = 4)

Je vois que vous êtes uniquement intéressé par l'existence d'un group_id, et pas de décompte réel. De plus, il n'y a que 133 group_idart. Par conséquent, votre requête peut être satisfaite avec le premier hit par gorup_iddans la période. D'où cette suggestion pour une requête alternative avec une EXISTSsemi-jointure :

En supposant une table de recherche pour les groupes:

SELECT group_id
FROM   groups g
WHERE  EXISTS (
   SELECT 1
   FROM   counter c
   WHERE  c.group_id = g.group_id
   AND    ts BETWEEN timestamp '2014-03-02 00:00:00'
                 AND timestamp '2014-03-05 12:00:00'
   );

Votre index comp_2_indexsur (group_id, ts)devient instrumental maintenant.

SQL Fiddle (s'appuyant sur le violon fourni par @ypercube dans les commentaires)

Ici, la requête préfère l'index (ts, group_id), mais je pense que c'est à cause de la configuration de test avec des horodatages "en cluster". Si vous supprimez les index avec interligne ts( plus à ce sujet ), le planificateur utilisera aussi volontiers l'index (group_id, ts)- notamment dans un scan d'index uniquement .

Si cela fonctionne, vous n'aurez peut-être pas besoin de cette autre amélioration possible: pré-agréger les données dans une vue matérialisée pour réduire considérablement le nombre de lignes. Cela aurait du sens en particulier si vous avez également besoin de chiffres réels . Ensuite, vous avez le coût de traiter plusieurs lignes une fois lors de la mise à jour du MV. Vous pouvez même combiner des agrégats quotidiens et horaires (deux tableaux distincts) et adapter votre requête à cela.

Les délais dans vos requêtes sont-ils arbitraires? Ou surtout en minutes / heures / jours complets?

CREATE MATERIALIZED VIEW counter_mv AS
SELECT date_trunc('hour', ts) AS hour
     , group_id
     , count(*) AS ct
GROUP BY 1,2
ORDER BY 1,2;

Créez le ou les index nécessaires counter_mvet adaptez votre requête pour qu'elle fonctionne ...