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 >>> >> >>
