Eu tenho uma estrutura de tabela particionada como:
CREATE TABLE measurements (
sensor_id bigint,
tx timestamp,
measurement int
);
CREATE TABLE measurements_201201(
CHECK (tx >= '2012-01-01 00:00:00'::timestamp without time zone
AND tx < ('2012-01-01 00:00:00'::timestamp without time zone + '1 mon'::interval))
)INHERITS (measurements);
CREATE INDEX ON measurements_201201(sensor_id);
CREATE INDEX ON measurements_201201(tx);
CREATE INDEX ON measurements_201201(sensor_id, tx);
....
E assim por diante. Cada tabela possui aproximadamente 20 milhões de linhas.
Se eu consultar uma amostra de sensores e uma amostra de registros de data e hora na WHERE
cláusula, o plano de consulta mostrará as tabelas corretas sendo selecionadas e os índices sendo usados, por exemplo:
SELECT *
FROM measurements
INNER JOIN sensors TABLESAMPLE BERNOULLI (0.01) USING (sensor_id)
WHERE tx BETWEEN '2015-01-04 05:00' AND '2015-01-04 06:00'
OR tx BETWEEN '2015-02-04 05:00' AND '2015-02-04 06:00'
OR tx BETWEEN '2014-03-05 05:00' AND '2014-04-07 06:00' ;
No entanto, se eu usar um CTE ou colocar os valores de carimbo de data / hora em uma tabela (não mostrados, mesmo com índices na tabela temporária).
WITH sensor_sample AS(
SELECT sensor_id, start_ts, end_ts
FROM sensors TABLESAMPLE BERNOULLI (0.01)
CROSS JOIN (VALUES (TIMESTAMP '2015-01-04 05:00', TIMESTAMP '2015-01-04 06:00'),
(TIMESTAMP '2015-02-04 05:00', TIMESTAMP '2015-02-04 06:00'),
(TIMESTAMP '2014-03-05 05:00', '2014-04-07 06:00') ) tstamps(start_ts, end_ts)
)
Algo como o abaixo
SET constraint_exclusion = on;
SELECT * FROM measurements
INNER JOIN sensor_sample USING (sensor_id)
WHERE tx BETWEEN start_ts AND end_ts
Executa uma verificação de índice em todas as tabelas. O que ainda é relativamente rápido, mas com a crescente complexidade das consultas, isso pode se transformar em verificações seq, que acabam sendo muito lentas para recuperar ~ 40K linhas de um subconjunto limitado de tabelas particionadas (4-5 de 50).
Eu estou preocupado que algo como este é o problema.
Para expressões não triviais, é necessário repetir a condição mais ou menos detalhada nas consultas para fazer com que o planejador de consultas do Postgres entenda que ele pode confiar na restrição CHECK. Mesmo que pareça redundante!
Como posso melhorar a estrutura de particionamento e consulta para reduzir a probabilidade de executar varreduras seq em todos os meus dados?