Extrañamente no volvimos a tener el problema de lentitud!!! fue solo ese
día y nunca mas!!
De todas maneras hice un script que lo dejo acá por si a alguien le sirve,
tomando la sugerencia de Horacio.
#!/bin/bash
TMP_FILE="/tmp/explain_tmp_$$.log"
LOG_FILE="/home/postgres/data/test.log"
START_TIM
Porque no usa auto_explain que escribe en el log el query plan? En ese
case, sabrias exactamente que plan se uso y de ahi ver si hace falta
un indice, o a lo mejor la consulta debe optimizarse de otra manera.
Igualmente, la optimizacion que estan buscando se llama "Upgrade" como
ya dijo Alvaro.
E
Puedes ver en pg_stat_statement como esa query esta usando la cache, si
tiene un alto % de utilizacion de la cache es muy seguro que la utilization
del IO no la affecte.
Si no la tienes instalada hay otras maneras de revisar como estas usando la
cache al nivel de base de datos en pg_stat_database.
Ojo, con ese script que corre la misma consulta cada min. y no tienes problemas
de velocidad me podría indicar que tal vez sea un tema de cache de la consulta,
que la saca de la RAM ( cache ).
Si la consulta no corre por un buen rato y se saca del cache, al correrla
fresca se podría demorar.
Extrañamente hoy la query anduvo bien, ya tengo armado el script sugerido
por Horacio pero por ahora no hay demoras.
Si hay demora, me va a dejar el plan en un log y se los muestro.
Muchas gracias!
El mar, 18 feb 2025 a las 12:41, Carlos T. Groero Carmona (<
cton...@gmail.com>) escribió:
> Guill
Guillermo, si logras capturar el plan y comparar, revisa el plan mode que
te comente, a mi me paso recientemente en la version 14, despues de
ejecutar la misma query con los mismos valores mas de 10 veces, la query
empieza a correr ridiculamente despacio, una query que corre desde mi
laptop en 85ms
Es buena idea Horacio, voy a armarla bien y luego les comento.
Muchas gracias.
El mar, 18 feb 2025 a las 6:38, Horacio Miranda ()
escribió:
> Y hacer un script que guarde el explain (buffers,analyze) select … cuando
> el time se demore mas de 10 segundos ?
>
> Lo corres a cada rato y de esa forma
Así es Alvaro, es demasiado vieja la versión, lamentablemente es un
problema que apareció ahora y está provocando importantes cuellos de
botella en el organismo en el que estoy. El pg17 va a demorar un poco en
implementarse porque hay factores externos (proveedor de sistema).
De todas maneras mucha
Guillermo E. Villanueva escribió:
> Buenas tardes, antes que nada, estoy usando una versión muy vieja de
> postgres por cuestiones contractuales y de un desarrollo de terceros, el
> proceso de upgrade a postgres 17 ya está iniciado, mientras tanto tengo un
> entorno de un postgres 9.2 con un master
Y hacer un script que guarde el explain (buffers,analyze) select … cuando el
time se demore mas de 10 segundos ?
Lo corres a cada rato y de esa forma capturas el plan malo vs el plan bueno ?
Algo como Lo dejas corriendo en el crontab, sera un poco pesado pero puede
darte luces del plan que e
Gracias por tu comentario, si puse la query, no usa prepare, va directo.
El El lun, 17 feb 2025 a la(s) 23:57, Carlos T. Groero Carmona <
cton...@gmail.com> escribió:
> Si, si estas usando prepared statements puede pasar, recisa esto:
> plan_cache_mode
>
> El valor por default is auto, trata de
Si quieres ajusta el sar para tomar muestras de 1 min para descartar que los
discos estén saturados.
Sobre la versión vieja de postgresql hace un set de pruebas debería funcionar
bien con claves tipo password y hasta la versión 13 si usas jdbc donde las
consultas mal hechas tiene el where pega
suponía que si!! puede tener diferentes planes para la misma query , mismos
valores? solo cambia el cliente
El lun, 17 feb 2025 a las 16:59, Carlos T. Groero Carmona (<
cton...@gmail.com>) escribió:
> Te da differentes planes y tiempo de ejecucion si la corres desde la
> applicacion y otro muy di
Te da differentes planes y tiempo de ejecucion si la corres desde la
applicacion y otro muy differente si lo ejecutas desde psql por ejemplo?
Regards,
Carlos
On Mon, Feb 17, 2025, 1:48 PM Guillermo E. Villanueva <
guillermo...@gmail.com> wrote:
> Buenas tardes, antes que nada, estoy usando una v
Buenas tardes, antes que nada, estoy usando una versión muy vieja de
postgres por cuestiones contractuales y de un desarrollo de terceros, el
proceso de upgrade a postgres 17 ya está iniciado, mientras tanto tengo un
entorno de un postgres 9.2 con un master y un slave con streaming.
La versión 9.2
15 matches
Mail list logo
