Eu tenho esta tabela:
CREATE TABLE spp.rtprices (
"interval" timestamp without time zone NOT NULL,
rtlmp numeric(12,6),
rtmcc numeric(12,6),
rtmcl numeric(12,6),
node_id integer NOT NULL,
CONSTRAINT rtprices_pkey PRIMARY KEY ("interval", node_id),
CONSTRAINT rtprices_node_id_fkey FOREIGN KEY (node_id)
REFERENCES spp.nodes (node_id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT
)
E mais um índice relevante:
CREATE INDEX rtprices_node_id_interval_idx ON spp.rtprices (node_id, "interval");
Contra isso, fiz esta opinião:
CREATE OR REPLACE VIEW spp.rtprices_hourly AS
SELECT (rtprices."interval" - '00:05:00'::interval)::date::timestamp without time zone AS pricedate,
date_part('hour'::text, date_trunc('hour'::text, rtprices."interval" - '00:05:00'::interval))::integer + 1 AS hour,
rtprices.node_id,
round(avg(rtprices.rtlmp), 2) AS rtlmp,
round(avg(rtprices.rtmcc), 2) AS rtmcc,
round(avg(rtprices.rtmcl), 2) AS rtmcl
FROM spp.rtprices
GROUP BY date_part('hour'::text, date_trunc('hour'::text, rtprices."interval" - '00:05:00'::interval))::integer + 1,
rtprices.node_id,
(rtprices."interval" - '00:05:00'::interval)::date::timestamp without time zone;
O objetivo é fornecer médias das colunas numéricas para cada hora (os timestamps têm dados a cada 5 minutos). O problema é que uma consulta de um único dia para um único node_id
leva mais de 30 segundos para 24 registros.
explain analyze select * from spp.rtprices_hourly
where node_id=20 and pricedate='2015-02-02'
Retorna isso :
"HashAggregate (cost=1128767.71..1128773.79 rows=135 width=28) (actual time=31155.023..31155.065 rows=24 loops=1)"
" Group Key: ((date_part('hour'::text, date_trunc('hour'::text, (rtprices."interval" - '00:05:00'::interval))))::integer + 1), rtprices.node_id, (((rtprices."interval" - '00:05:00'::interval))::date)::timestamp without time zone"
" -> Bitmap Heap Scan on rtprices (cost=10629.42..1128732.91 rows=2320 width=28) (actual time=25071.410..31153.715 rows=288 loops=1)"
" Recheck Cond: (node_id = 20)"
" Rows Removed by Index Recheck: 7142233"
" Filter: (((("interval" - '00:05:00'::interval))::date)::timestamp without time zone = '2015-02-02 00:00:00'::timestamp without time zone)"
" Rows Removed by Filter: 124909"
" Heap Blocks: exact=43076 lossy=82085"
" -> Bitmap Index Scan on rtprices_node_id_interval_idx (cost=0.00..10628.84 rows=464036 width=0) (actual time=68.999..68.999 rows=125197 loops=1)"
" Index Cond: (node_id = 20)"
"Planning time: 5.243 ms"
"Execution time: 31155.392 ms"
Visualização mais simples
Para este objetivo:
.. parece tão bom truncar para horas completas, que é mais simples e barato:
consulta mais rápida
De qualquer forma, uma consulta equivalente na exibição com predicados sargáveis seria:
Isso é mais rápido, mas ainda não tão rápido quanto poderia ser. O maior impacto no desempenho ocorre porque o índice só pode ser usado com uma condição de índice em
node_id
, que é preservada em seu estado original na exibição. É por isso que seu índicertprices_node_id_interval_idx
com onode_id
primeiro é importante. Por quê?O segundo predicado
hour
deve ser filtrado depois que a tupla foi buscada no heap (a linha foi lida da tabela). A grande maioria das linhas é descartada no final do processo, muito trabalho para nada .Muito mais rápido com consulta direta
Seria muito mais rápido executar a consulta original e aplicar predicados antes de agregar:
Você verá as condições de índice para todos os predicados agora. O índice mais eficiente ainda é aquele com o
node_id
primeiro. Por quê?Rápido e curto: crie uma função
Portanto, isso não funcionará bem com uma exibição. Em vez disso, use uma função:
Agora você obtém o melhor desempenho com uma consulta simples:
Eu coloquei um recurso de conveniência, o segundo parâmetro é padronizado como "um dia depois" se você omitir:
Mais sobre parâmetros de função e valores padrão:
Você pode consultar qualquer intervalo: