Impacto de CLUSTER en el rendimiento

Estoy tratando de optimizar mi base de datos Postgres 9.2 para acelerar las consultas con restricciones de fecha.

Tengo una timestampcolumna, pero sobre todo estoy pidiendo algún día, así que he creado un índice timestamppara dateanalizar:

CREATE INDEX foo_my_timestamp_idx
ON foo
USING btree
((my_timestamp::date) DESC);

Ahora, para aumentar una CLUSTER footabla de rendimiento I usando el índice anterior:

CLUSTER foo USING foo_my_timestamp_idx;

Según el manual sobre SQL-CLUSTER , la tabla

se reordena físicamente en función de la información del índice

Me pregunto si hay un impacto en el rendimiento para otras consultas que usan un PK de tabla (digamos id_foo). ¿Hay alguna desventaja?

Sí, puede haber inconvenientes. Si otra consulta examina un segmento de datos diferente que no está determinado por la fecha, podría tener un impacto en el rendimiento si las filas se extienden en más páginas de datos ahora. De la misma manera que su primera consulta se beneficia. Eso depende completamente de la información que no está en su pregunta.

otras consultas usando un PK de tabla (digamos id_foo)

Eso podría ser cualquier cosa . Depende de lo que tenga y de lo que consulte exactamente . La consulta de una sola fila no se ve afectada de ninguna manera, pero pueden serlo varias filas.

Tenga en cuenta que CLUSTERreescribe la tabla en perfecto estado como lo VACUUM FULLhace (elimina las tuplas muertas, compacta el tamaño físico de la tabla, reescribe los índices). Por lo tanto, es posible que vea un efecto positivo inmediato en el rendimiento de lectura independientemente del orden de clasificación. (Al igual que lo haría con VACUUM FULL).
Después CLUSTER, es posible que también desee ejecutar un plano VACUUMen la tabla para actualizar el mapa de visibilidad , lo que puede permitir escaneos de solo índice.

Todos los beneficios de CLUSTERreducir con la frecuencia de escritura.

Además, si tiene muchas actualizaciones en la tabla, CLUSTERpuede dañar el rendimiento de escritura al eliminar el "margen de maniobra" para las actualizaciones CALIENTES en la misma página de datos. Es posible que pueda contrarrestar ese efecto con una FILLFACTORconfiguración inferior a 100. De nuevo, depende de la localidad de las filas actualizadas, etc.

Relacionado:

• Optimización de índice con fechas

De cualquier manera, probablemente no indexaría ni agruparía my_timestamp::date, sino my_timestampdirectamente. Nada perdido, algo ganado. El yeso es muy barato, pero aún así es más barato no lanzarlo en absoluto. Y el índice puede admitir más consultas.

CREATE INDEX foo_my_timestamp_idx ON foo (my_timestamp);

Aunque un dateocupa solo 4 bytes en el disco y timestampocupa 8 bytes, la diferencia generalmente se pierde con el relleno de alineación para su caso, y ambos índices tienen exactamente el mismo tamaño.

El orden de varias filas en el mismo día resultante de su índice de expresión es arbitrario. Todavía puede haber dos marcas de tiempo idénticas, pero con 6 dígitos fraccionarios eso normalmente es muy poco probable. Aparte de eso, obtienes un orden determinista de filas, que puede tener varias ventajas.

También eliminé la DESCpalabra clave, ya que Postgres puede leer índices hacia atrás prácticamente tan rápido como hacia adelante. (¡Sin embargo, el orden de clasificación es importante para los índices de varias columnas!) Más:

• Optimización de consultas en un rango de marcas de tiempo (dos columnas)

En vez de:

SELECT * FROM foo
WHERE my_timestamp::date = '2016-07-25';

Ahora usarías:

SELECT * FROM foo
WHERE  my_timestamp >= '2016-07-25'  -- this is a timestamp literal now
WHERE  my_timestamp <  '2016-07-26';

Mismo rendimiento.

Si no necesita el componente de tiempo de la columna en absoluto , convertir la columna a date...

¿Cómo retroceder CLUSTER?

CLUSTERen una sola tabla se puede revertir con ROLLBACKcualquier otro comando regular siempre que la transacción no se haya confirmado.

Sin embargo, cito el manual :

CLUSTERsin ningún parámetro vuelve a agrupar todas las tablas agrupadas previamente en la base de datos actual que posee el usuario llamante, o todas esas tablas si son llamadas por un superusuario. Esta forma de CLUSTERno se puede ejecutar dentro de un bloque de transacciones.

Siempre puede ejecutar CLUSTERcon un índice diferente para cambiar el orden físico de las filas una vez más.