¿Cuántas particiones de tabla hay demasiadas en Postgres?

Question

Participo una tabla muy grande que contiene datos temporales, y considerando a qué granularidad debo hacer las particiones. El Postgres partition documentation afirma que "es probable que un gran número de particiones aumente considerablemente el tiempo de planificación de consultas" y recomienda que el particionamiento se use con particiones de "hasta quizás cien".

Asumiendo que mi tabla contiene diez años de datos, si participo por semana terminaría con más de 500 particiones. Antes de descartar esto, me gustaría entender mejor qué impacto tiene la cantidad de particiones en el tiempo de planificación de consultas. ¿Alguien ha comparado esto, o alguien entiende cómo funciona esto internamente?

Answer 1

El planificador de consultas tiene que hacer una búsqueda lineal de la información de restricción para cada partición de tablas utilizadas en la consulta, para determinar cuáles están realmente involucradas, las que pueden tener filas necesarias para los datos solicitados. La cantidad de planes de consulta que el planificador considera crece exponencialmente a medida que se une a más tablas. Entonces, el lugar exacto donde esa búsqueda lineal se suma al tiempo suficiente para ser problemático realmente depende de la complejidad de la consulta. Cuantas más combinaciones, peor será golpeado por esto. La cifra de "hasta cien" surgió de la observación de que el tiempo de planificación de consultas se estaba sumando a una cantidad de tiempo no trivial incluso en consultas más simples en ese punto. En aplicaciones web en particular, donde la latencia del tiempo de respuesta es importante, eso es un problema; por lo tanto, la advertencia.

¿Puedes apoyar 500? Por supuesto.Pero va a buscar cada una de las 500 restricciones de verificación para cada plan de consulta que involucre esa tabla considerada por el optimizador. Si el tiempo de planificación de consultas no le preocupa, tal vez no le importe. Pero la mayoría de los sitios terminan disgustando la proporción de tiempo dedicado a la planificación de consultas con tantas particiones, que es una de las razones por las que el partición mensual es el estándar para la mayoría de los conjuntos de datos. Puede almacenar fácilmente 10 años de datos, divididos mensualmente, antes de comenzar a cruzar hacia donde comienza a notarse la sobrecarga de planificación.

Answer 2

Si no quiere confiar en los desarrolladores de PostgreSQL que escribieron el código, entonces le recomiendo que simplemente lo intente por su cuenta y ejecute algunas consultas de ejemplo con explicar analice y calcule el tiempo utilizando diferentes esquemas de partición. Es probable que su configuración específica de hardware y software domine cualquier respuesta en cualquier caso.

Supongo que el caché de optimización de filas que el optimizador de consultas utiliza para determinar qué uniones y restricciones usar se almacena con cada partición, por lo que probablemente necesite cargar y leer partes de cada partición para planificar la consulta.

Answer 3

Cada partición de tabla toma un inodo en el sistema de archivos. "Muy grande" es un término relativo que depende de las características de rendimiento de su sistema de archivos de su elección. Si desea puntos de referencia de rendimiento explícitos, probablemente pueda ver varios puntos de referencia de rendimiento de los sistemas de correo de su SO y FS de su elección. En términos generales, no me preocuparía hasta que llegue a las decenas de miles o cientos de miles de espacios de tabla (usando dirhash en FreeBSD, sería UFS2 el que ganaría). También tenga en cuenta que esta misma limitación se aplica a DATABASES, TABLES o cualquier otro objeto de base de datos respaldado por el sistema de archivos en PostgreSQL.

Answer 4

"es probable que un gran número de particiones aumenten considerablemente el tiempo de planificación de consultas" y recomienda que las particiones se utilicen con particiones de "hasta quizás cien".

Porque cada partición extra generalmente estará ligada para verificar las restricciones, y esto llevará al planificador a preguntarse cuál de las particiones debe ser consultada. En el mejor de los casos, el planificador identifica que solo está golpeando una sola partición y se deshace del paso append.

En términos de filas, y como DNS y Seth han señalado, su kilometraje variará con el hardware. En general, sin embargo, no hay diferencia significativa entre consultar una tabla de 1M y una de 10M, especialmente si sus discos duros permiten un acceso aleatorio rápido y si están agrupados (consulte la declaración cluster) usando el índice que más le convenga. golpeando con frecuencia.