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

Outra ideia, que também usa a groupstabela e uma construção chamada LATERALjoin (para os fãs do SQL-Server, isso é quase idêntico ao OUTER APPLY). Tem a vantagem de que os 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 faz varreduras de índice no (group_id, ts)índice.

Planos semelhantes são produzidos usando 2 junções laterais, uma para min e outra para max e também com 2 subconsultas correlacionadas em linha. Eles também podem ser usados ​​se você precisar mostrar todas as counterlinhas 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 um agregado na lista de seleção, o the group byé praticamente o mesmo que colocar um distinctna lista de seleção, certo?

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

Faça uma visualizaçã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 visualização no lugar da tabela de pesquisa na semijunção de Erwin exists.

Como existem apenas 133 different group_id's, você pode usar integer(ou mesmo smallint) para o group_id. Porém, não vai comprar muito, porque o preenchimento de 8 bytes consumirá o restante da tabela e possíveis índices de várias colunas. Processamento de 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: timestamps são armazenados como números inteiros de 8 bytes em instalações modernas e podem ser processados ​​perfeitamente rápido. Detalhes.

@ypercube: O índice (group_id, ts)não pode ajudar, pois não há 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ê está interessado apenas na existência de um 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_idno período de tempo. Daí esta sugestão para uma consulta alternativa com um EXISTSsemi-join :

Assumindo 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 torna comp_2_index- (group_id, ts)se instrumental agora.

SQL Fiddle (com base no violino fornecido por @ypercube nos comentários)

Aqui, a consulta prefere o índice em (ts, group_id), mas acho que é por causa da configuração do teste com registros de data e hora "agrupados". Se você remover os índices com entrelinha ts( mais sobre isso ), o planejador também usará o índice (group_id, ts)- notavelmente em uma varredura somente de índice .

Se isso funcionar, talvez você não precise desta outra melhoria possível: pré-agregue os dados em uma visualização materializada para reduzir drasticamente o número de linhas. Isso faria sentido em particular, se você também precisar de contagens reais adicionais. 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 em 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...