Índices para consulta SQL com a condição WHERE e GROUP BY

Estou tentando determinar quais índices usar para uma consulta SQL com uma WHEREcondição e uma GROUP BYque está sendo executada muito lentamente.

Minha consulta:

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

A tabela atualmente possui 32.000.000 linhas. O tempo de execução da consulta aumenta muito quando eu aumento o prazo.

A tabela em questão fica assim:

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

Atualmente, tenho os seguintes índices, mas o desempenho ainda é lento:

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);

A execução de EXPLAIN na consulta fornece o seguinte resultado:

"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 com dados de exemplo: http://sqlfiddle.com/#!15/7492b/1

A questão

É possível melhorar o desempenho desta consulta adicionando índices melhores ou devo aumentar o poder de processamento?

Editar 1

O PostgreSQL versão 9.3.2 é usado.

Editar 2

Tentei a proposta de @Erwin com 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'
   );

Infelizmente, isso não pareceu aumentar o desempenho. O plano de consulta:

"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))"

Editar 3

O plano de consulta para a consulta LATERAL do 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))"

Outra idéia, que também usa a groupstabela e uma construção chamada LATERALjoin (para os fãs do SQL Server, isso é quase idêntico a OUTER APPLY). Tem a vantagem de que agregados podem ser calculados na subconsulta:

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 ;

O teste no SQL-Fiddle mostra que a consulta indexa verificações no (group_id, ts)índice.

Planos similares são produzidos usando 2 junções laterais, uma para min e outra para max e também com 2 subconsultas correlatas em linha. Eles também podem ser usados ​​se você precisar mostrar as counterlinhas inteiras além das datas mínima e máxima:

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 ;

Como você não tem agregado na lista de seleção, o valor group byé praticamente o mesmo que colocar um distinctna lista de seleção, certo?

Se é isso que você deseja, poderá obter uma pesquisa rápida de índice em comp_2_index, reescrevendo-a para usar uma consulta recursiva, conforme descrito no wiki do PostgreSQL .

Faça uma exibição para retornar eficientemente os group_ids distintos:

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));

E, em seguida, use essa exibição no lugar da tabela de pesquisa na existssemi-junção de Erwin .

Como existem apenas 133 different group_id's, você pode usar integer(ou até smallint) para o group_id. Porém, não vai lhe custar muito, porque o preenchimento de 8 bytes consumirá o restante da sua tabela e possíveis índices de várias colunas. O processamento da planície integerdeve ser um pouco mais rápido, no entanto. Mais sobre intvs.int2 .

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

@ Leo: os carimbos de data / hora são armazenados como números inteiros de 8 bytes em instalações modernas e podem ser processados ​​perfeitamente rapidamente. Detalhes.

@ ypercube: o índice em (group_id, ts)não pode ajudar, pois não há nenhuma condição group_idna consulta.

Seu principal problema é a enorme quantidade de dados que precisam ser processados:

Varredura de índice usando ts_index no contador (custo = 0,56..467470,93 linhas = 194892 largura = 4)

Vejo que você só está interessado na existência de a group_id, e nenhuma contagem real. Além disso, existem apenas 133 group_ids diferentes . Portanto, sua consulta pode ser satisfeita com o primeiro hit por gorup_idperíodo de tempo. Daí esta sugestão para uma consulta alternativa com uma EXISTSsemi-junção :

Supondo uma tabela de pesquisa para grupos:

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'
   );

Seu índice comp_2_indexem (group_id, ts)torna-se fundamental agora.

SQL Fiddle (baseado no fiddle fornecido por @ypercube nos comentários)

Aqui, a consulta prefere o índice (ts, group_id), mas acho que é por causa da configuração de teste com carimbos de data e hora "agrupados". Se você remover os índices com as iniciais ts( mais sobre isso ), o planejador também utilizará o índice com prazer (group_id, ts)- principalmente em uma Varredura de Índice .

Se isso funcionar, talvez você não precise dessa outra melhoria possível: Pré-agregue dados em uma exibição materializada para reduzir drasticamente o número de linhas. Isso faria sentido, em particular, se você também precisar de contagens reais adicionalmente. Então você tem o custo de processar muitas linhas uma vez ao atualizar o mv. Você pode até combinar agregados diários e horários (duas tabelas separadas) e adaptar sua consulta a isso.

Os prazos nas suas consultas são arbitrários? Ou principalmente em minutos / horas / dias completos?

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;

Crie o (s) índice (s) necessário (s) counter_mve adapte sua consulta para trabalhar com ele ...