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. On Tue, Feb 18, 2025, 2:51 PM Horacio Miranda <hmira...@gmail.com> wrote: > 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 >>>>> >>>> >>>> >
