Re: PG11: particionado, parallel query y performance

Muchas gracias Álvaro.

Dedicaré esfuerzos en los puntos que has remarcado y continuaremos adelante
con el cambio.

Esperemos haber tomado una buena decisión. ;-)

Saludos

On Tue, 9 Jul 2019 at 15:20, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> 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
>

--
*Ruben Fitó *
Software Engineer
[image: Ubiquat Technologies, SL]
r(dot)fito(at)ubiquat(dot)com <j(dot)catarineu(at)ubiquat(dot)com>
www.ubiquat.com
Tota la informació continguda en aquest document i arxius adjunts és
CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per
error, si us plau elimini'l i posi's en contacte amb l'emissor.

All information contained in this document and any attachments are
CONFIDENTIAL and protected under trade secret laws. If you receive this
message by mistake, please delete it and notify it immediately to the
sender.