From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Ruben Fitó <r(dot)fito(at)ubiquat(dot)com> |
Cc: | Ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: PG11: particionado, parallel query y performance |
Date: | 2019-08-08 16:27:20 |
Message-ID: | 20190808162720.GA19835@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Ruben Fitó escribió:
> Entiendo que:
>
> - Me ahorraría el pool (tanto escritura como lectura) en nuevos
> aplicativos.
Sí, puede ser.
> - No tendría que preocuparme del número de conexiones en postgres.
Correcto.
> - Reduciría carga de sistema?
Más que seguro que sí. Abrir conexiones en Postgres es bastante pesado;
abrirlas en el pooler y permitir que éste las mantenga abiertas a Postgres
es muchísimo mejor.
> - Que tal los tiempos de respuesta? Lo pregunto ya que tenemos un
> intermediario y creo que eso puede tener una penalización.
Se supone que es liviano, aunque pgpool tiene un montón de cosas
adicionales a la tarea del pool propiamente dicho. pgbouncer se nota
muy poco. Hay un pooler de conexiones nuevo de los rusos que dicen que
funciona mejor que pgbouncer, Odyssey, aunque desconozco en qué estado está.
Yo consideraría la idea de usar un pooler más liviano que pgpool (como
pgbouncer que ya está "probado en batalla" u Odyssey, que es tecnología
más nueva y por lo tanto más verde pero es mejor en papel), y mantener
la arquitectura de que las apps sepan de conexiones separadas para
escritura vs. lectura.
Saludos
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | kernel | 2019-08-08 17:35:16 | Re: Problemas de tamaño/recodificacion |
Previous Message | Alvaro Herrera | 2019-08-08 16:21:07 | Re: Mejorar cola de trabajos |