From: | Hellmuth Vargas <hivs77(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Ruben Fitó <r(dot)fito(at)ubiquat(dot)com>, Lista Postgres ES <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: PG11: particionado, parallel query y performance |
Date: | 2019-07-12 10:24:57 |
Message-ID: | CAN3Qy4o53Xi3appRz-rXnNCuB2=TtvJNx7=OM7LzZtFFc+haKQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Hola Alvaro
Me llama la atención lo que menciona sobre las limitaciones del
particionamiento y la replicación lógica, no puede indicar a que
limitaciones se refiere... Estoy también interesado en implementar una
solución basado en esto... De antemano muchas gracias
El mar., 9 de jul. de 2019 8:20 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
escribió:
> Ruben Fitó escribió:
>
> Hola
>
> > - Nuestro objetivo para el uso de particionado(por año) es la de
> evitar
> > hacer purgados.
>
> Excelente, ese es uno de los principales motivos para particionar.
>
> > - El otro objetivo es de optimizar consultas porque reducimos el
> volumen
> > de datos por tabla.
>
> Cierto, siempre y cuando esas consultas tengan que recorrer grandes
> porciones de las tablas. Si tus consultas usan mayormente recorridos
> localizados de índice, no ganarás mucho con particionar.
>
> > - Si una consulta afecta a varias tablas particionadas, cómo afecta al
> > rendimiento. "Parallel query" ayuda? Entiendo que los índices se
> heredan en
> > PG11, ...
>
> El particionamiento ayuda a las consultas sobre todo porque ocurre
> "pruning",
> es decir que el optimizador puede evitar recorrer las particiones que
> pueda demostrar (basado en los WHERE y demás) que no necesita recorrer.
> Parallel query ayuda tal como si fuera una consulta sobre una sola
> tabla. Los índices se "heredan" pero esto sólo quiere decir que los
> índices se crean automáticamente en las particiones; no tiene ninguna
> implicancia desde el punto de vista de la optimización de la consulta.
>
> > - Cuándo tiene efecto el "Parallel query"?
>
> Siempre que sea útil.
>
> > - Qué tal han trabajado con JIT?
>
> Está bueno, puede darte un pequeño % de mejora pero no esperes nada muy
> increíble todavía. Quizás en un par de años más. Pero sí está algo
> verde en algunas partes, así que pruébalo con cuidado y reporta
> cualquier comportamiento inesperado o sospechoso.
>
> > - ¿Qué debería tener en cuenta en el momento que empiece a trabajar
> con
> > particionado? Algún consejo, alguna mala experiencia, alguna buena...
>
> Aconsejo probar las operaciones que vas a realizar con cantidades
> razonables de datos, y verificar los planes de ejecución.
>
> Ojo con las definiciones de índices. Hay algunas limitaciones ... por
> ej. si tienes llaves primarias en las tablas particionadas, la PK debe
> incluir la llave de partición.
>
> > - Cómo funciona el particionado con Streaming Replication?
>
> No afecta. Son ortogonales.
>
> > - Y con Logical replication? → Supongo que he de crear todas las
> tablas
> > igual que en master... también se heredan índices?
>
> La replicación lógica tiene algunas limitaciones todavía con tablas
> particionadas. Recomiendo probar con cuidado.
>
> En resumen: es mejor que el año anterior, pero podría ser mejor, y
> seguro que el próximo año será mejor.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Martín Marqués | 2019-07-14 20:05:26 | Re: PG11: particionado, parallel query y performance |
Previous Message | Haroon | 2019-07-10 15:47:14 | Re: Instalacion desatendida de Postgres |