Timeouts en cascada a través del Pool (PGBouncer)
query_timeout de Pgbouncer y statement_timeout de Postgres
Series: Postgres
Combinando query_timeout y statement_timeout
En la documentación de pgbouncer se establece que el query_timeout debería configurarse ligeramente
más alto que el statement_timeout de Postgres. Aunque esto aplica en la mayoría de los casos, depende
de los requisitos del negocio.
Generalmente, el statement_timeout debería configurarse al percentil 99 de la duración de tus statements.
Sin embargo, hay casos donde ciertos statements requieren timeouts más largos, debido a particularidades como
un conjunto grande de clientes, o campos más grandes, como en casos de compresión TOAST.
La siguiente secuencia describe lo que sucedería si el query_timeout se configura a un valor ligeramente
más alto que el statement_timeout:
(5 or default) Postgres-->>-PgBouncer: statement_timeout PgBouncer--X Application: Timeout PgBouncer->>PgBouncer: Apply query_timeout PgBouncer-->>-Application: query_timeout Postgres--X Application: Non-applicable custom statement_timeout
Puedes estar preguntándote sobre esos casos que requieren una configuración de timeout diferente. Un enfoque
probablemente recomendado sería configurar el query_timeout a un valor que signifique una especie de
límite duro en términos de tiempo de ejecución. Entonces, lo ideal sería tener este timeout por encima
del statement_timeout tan grande como para cubrir consultas de ejecución de casos extremos.
Es decir, en el caso de un statement_timeout por defecto de 30 segundos y un statement_timeout personalizado
de 60 segundos para la consulta más larga, el query_timeout podría configurarse a un poco más de 60 segundos.
Conclusion
Usa query_timeout como un límite duro para la duración de la consulta, y statement_timeout como un límite “suave”.