Re: intermitente query lenta

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
(<hmiranda(at)gmail(dot)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 <guillermovil(at)gmail(dot)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 (<ctonetg(at)gmail(dot)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 <guillermovil(at)gmail(dot)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 (<hmiranda(at)gmail(dot)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 <guillermovil(at)gmail(dot)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 <ctonetg(at)gmail(dot)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