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. El mar, 18 feb 2025 a las 21:52, Horacio Miranda (<hmira...@gmail.com>) escribió: > > 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. Ignoro que parametros tienes a nivel de disco en > esa version, pero puede indicar algo del LRU cache. En Oracle puedes hacer > que una tabla este en memoria en postgresSQL eso creo que no se puede hacer y > no tiene mucho sentido por algo que se converso hace muchos años atras cuando > hice esa pregunta, recuerdo que Alvaro mensiono que para estan los LRU y que > no tenia sentido y estoy de acuerdo, dicho esto puede que tengas que revisar > el tamaño del cache. > > Sobre velocidad del disco, que S.O estas usando y filesystem ? dependiendo > del filesystem puede que tengas que defragmentar. > > NOTA: Al correr cada minuto esa consulta lo que haces es que el LRU de esa > consulta se refresca y el plan sigue en memoria. > > > > On 19 Feb 2025, at 4:58 AM, Guillermo E. Villanueva <guillermo...@gmail.com> > wrote: > > 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ó: >> >> 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 >> estaba demorando en ocaciones 27 seg. >> >> La razon no fue network lag, no fue saturacion en el hardware, fue >> specificamente como postgres determinaba que plan usar despues de correr 9 o >> 10 veces la misma query desde la applicacion. >> >> >> On Tue, Feb 18, 2025, 4:43 AM Guillermo E. Villanueva >> <guillermo...@gmail.com> wrote: >>> >>> 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 (<hmira...@gmail.com>) >>> 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 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 esta siguiendo. >>>> >>>> #!/bin/bash >>>> FILE=/tmp/output_$(date +%Y%m%d%H%M)”.log >>>> >>>> SECONDS=0 >>>> psql < consulta.sql > /tmp/output.txt >>>> if [ $SECONDS -gt 10 ] ; then >>>> cp /tmp/output.txt $FILE >>>> echo “Revisar $FILE >>>> fi >>>> >>>> >>>> >>>> On 18 Feb 2025, at 3:59 PM, Guillermo E. Villanueva >>>> <guillermo...@gmail.com> wrote: >>>> >>>> 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 cambiarlo a forced_custom_plan >>>>> >>>>> Regards, >>>>> Carlos >>>> >>>> > -- Martín Marqués It’s not that I have something to hide, it’s that I have nothing I want you to see
