Agilizando una consulta de grupo por fecha en una gran mesa en postgres

Question

Tengo una tabla con alrededor de 20 millones de filas. Por razones de argumentos, digamos que hay dos columnas en la tabla: una identificación y una marca de tiempo. Estoy tratando de contar el número de artículos por día. Esto es lo que tengo en este momento.

SELECT DATE(timestamp) AS day, COUNT(*) 
    FROM actions 
    WHERE DATE(timestamp) >= '20100101' 
    AND DATE(timestamp) < '20110101' 
GROUP BY day; 

Sin ningún índice, esto toma alrededor de 30 segundos para funcionar en mi máquina. Aquí está la salida explicar analizar:

GroupAggregate (cost=675462.78..676813.42 rows=46532 width=8) (actual time=24467.404..32417.643 rows=346 loops=1) 
    -> Sort (cost=675462.78..675680.34 rows=87021 width=8) (actual time=24466.730..29071.438 rows=17321121 loops=1) 
     Sort Key: (date("timestamp")) 
     Sort Method: external merge Disk: 372496kB 
     -> Seq Scan on actions (cost=0.00..667133.11 rows=87021 width=8) (actual time=1.981..12368.186 rows=17321121 loops=1) 
       Filter: ((date("timestamp") >= '2010-01-01'::date) AND (date("timestamp") < '2011-01-01'::date)) 
Total runtime: 32447.762 ms 

Desde que estoy viendo un recorrido secuencial, he tratado de índice en la fecha agregada

CREATE INDEX ON actions (DATE(timestamp)); 

que corta la velocidad en un 50%.

HashAggregate (cost=796710.64..796716.19 rows=370 width=8) (actual time=17038.503..17038.590 rows=346 loops=1) 
    -> Seq Scan on actions (cost=0.00..710202.27 rows=17301674 width=8) (actual time=1.745..12080.877 rows=17321121 loops=1) 
     Filter: ((date("timestamp") >= '2010-01-01'::date) AND (date("timestamp") < '2011-01-01'::date)) 
Total runtime: 17038.663 ms 

Soy nuevo en este negocio de optimización de consultas, y no tengo ni idea de qué hacer a continuación. ¿Alguna pista de cómo puedo hacer que esta consulta se ejecute más rápido?

--edit--

Parece que estoy golpeando los límites de los índices. Esta es prácticamente la única consulta que se ejecuta en esta tabla (aunque los valores de las fechas cambian). ¿Hay alguna forma de particionar la tabla? ¿O crear una tabla de caché con todos los valores de conteo? O alguna otra opción?

Answer 1

¿Hay alguna manera de particionar la tabla?

Sí:
http://www.postgresql.org/docs/current/static/ddl-partitioning.html

o crear una tabla de caché con todos los valores de recuento? O alguna otra opción?

Crear una tabla de "caché" ciertamente es posible. Pero esto depende de la frecuencia con la que necesite ese resultado y de la precisión que necesita.

 
CREATE TABLE action_report 
AS 
SELECT DATE(timestamp) AS day, COUNT(*) 
    FROM actions 
    WHERE DATE(timestamp) >= '20100101' 
    AND DATE(timestamp) < '20110101' 
GROUP BY day; 

A continuación, un SELECT * FROM action_report le dará lo que quiere en el momento oportuno. Luego programaría un trabajo cron para recrear esa tabla de forma regular.

Este enfoque, por supuesto, no ayudará si el rango de tiempo cambia con cada consulta o si esa consulta solo se ejecuta una vez al día.

Answer 2

Parece que la gama cubre casi todos los datos disponibles.

Esto podría ser un problema de diseño. Si va a ejecutar esto a menudo, es mejor que cree una columna timestamp_date que contenga solo la fecha. Luego, cree un índice en esa columna y cambie la consulta en consecuencia. La columna debe mantenerse insertada + activadores de actualización.

SELECT timestamp_date AS day, COUNT(*) 
FROM actions 
WHERE timestamp_date >= '20100101' 
    AND timestamp_date < '20110101' 
GROUP BY day; 

Si estoy equivocado sobre el número de filas del intervalo de fechas se encuentra (y es sólo un pequeño subconjunto), entonces usted puede intentar un índice en solo la columna de marca de tiempo en sí, la aplicación de la cláusula WHERE a poco la columna (que le dio el rango funciona igual de bien)

SELECT DATE(timestamp) AS day, COUNT(*) 
FROM actions 
WHERE timestamp >= '20100101' 
    AND timestamp < '20110101' 
GROUP BY day; 

Answer 3

intente ejecutar explain analyze verbose ... para ver si el agregado está utilizando un archivo temporal. Tal vez aumentar work_mem para permitir que se haga más en la memoria?

Answer 4

En general, la mayoría de las bases de datos ignorarán los índices si el número esperado de filas devuelto va a ser alto. Esto se debe a que para cada hit de índice, deberá encontrar la fila también, por lo que es más rápido realizar un escaneo completo de la tabla. Este número está entre 10,000 y 100,000. Puedes experimentar con esto al reducir el rango de fechas y ver dónde postgres cambia a usar el índice. En este caso, postgres planea escanear 17.301.674 filas, por lo que su tabla es bastante grande. Si lo haces realmente pequeño y todavía sientes que postgres está haciendo una elección incorrecta, intenta ejecutar un análisis sobre la mesa para que postgres obtenga sus aproximaciones correctas.

Answer 5

Establezca work_mem para decir 2GB y vea si eso cambia el plan. Si no es así, es posible que no tenga opciones.

Answer 6

Lo que realmente desea para tales consultas de tipo DSS es una tabla de fechas que describe los días. En el lenguaje de diseño de bases de datos se llama una dimensión de fecha. Para rellenar dicha tabla, puede usar el código que publiqué en este artículo: http://www.mockbites.com/articles/tech/data_mart_temporal

Luego, en cada fila de su tabla de acciones, coloque la fecha_clave adecuada.

Su consulta se convierte entonces en:

SELECT 
    d.full_date, COUNT(*) 
FROM actions a 
JOIN date_dimension d 
    ON a.date_key = d.date_key 
WHERE d.full_date = '2010/01/01' 
GROUP BY d.full_date 

Suponiendo índices en las teclas y FULL_DATE, esto será muy rápida debido a que opera en las teclas INT4!

Otra ventaja es que ahora puedes dividir y cortar por cualquier otra columna de date_dimension (s).