Re: intermitente query lenta

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 <
guillermovil(at)gmail(dot)com> wrote:

> 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 está discontinuada de hace mucho así que si quieren dejar
> de leer acá, está todo bien.
>
>
> Tengo una extraña situación con esta query:
>
> SELECT
> OI.org_cod organismoId,
> TE.tex_cod expedienteTipo,
> CASE WHEN AE.exp_idacum IS NOT NULL THEN EA.exp_numero
> ELSE E.exp_numero END expedienteNumero,
> CASE WHEN AE.exp_idacum IS NOT NULL THEN EA.exp_anio ELSE
> E.exp_anio END expedienteAnio,
> E.exp_fecreg expedienteFecha,
> CASE WHEN AE.exp_idacum IS NOT NULL THEN
> REGEXP_REPLACE(EA.exp_carat,'[^a-zA-Z0-9 ,.áéíóúÁÉÍÓÚ]','', 'g') ELSE
> REGEXP_REPLACE(E.exp_carat,'[^a-zA-Z0-9 ,.áéíóúÁÉÍÓÚ]','', 'g') END
> expedienteCaratula,
> A.act_id actuacionId,
> A.act_numero actuacionNumero,
> AF.a_fir_fecha actuacionFechaFirma,
> REGEXP_REPLACE(A.act_titulo,'[^a-zA-Z0-9
> ,.áéíóúÁÉÍÓÚ]','', 'g') actuacionTitulo,
> CASE
> --WHEN AF.a_fir_fecha::date>='17/11/2020'::date
> THEN UF.usr_nombre
>
> WHEN AF.a_fir_fecha>=date_trunc('day', TIMESTAMP
> '2020-11-17 00:00') THEN UF.usr_nombre ------- Ajuste Formato de
> Fecha 17-02-2025
> ELSE OI.org_descorta || '-'|| 'JUEZ'
> END actuacionUsuarioFirmante,
> REGEXP_REPLACE(A.act_titulo,'[^a-zA-Z0-9
> ,.áéíóúÁÉÍÓÚ]','', 'g') actuacionTipo,
> encode(A.act_pdf, 'base64') actuacionArchivoPdf,
> REGEXP_REPLACE(AA.aac_nombre,'[^a-zA-Z0-9
> ,.áéíóúÁÉÍÓÚ]','', 'g') adjuntoNombre,
> encode(AA.aac_adj, 'base64') adjuntoArchivo
> FROM
> act A INNER JOIN
> exp E ON (A.exp_id = E.exp_id) INNER JOIN
> tex TE ON (E.tex_id = TE.tex_id) INNER JOIN
> org OI ON (E.org_idradactual = OI.org_id) INNER JOIN
> act_fir AF ON A.act_id = AF.act_id INNER JOIN
> usr UF ON AF.usr_id = UF.usr_id LEFT JOIN
> aac AA ON A.act_id = AA.act_id LEFT JOIN
> aex AE ON E.exp_id = AE.exp_idacum LEFT JOIN
> exp EA ON (AE.exp_id = EA.exp_id)
> WHERE E.exp_id IS NOT NULL AND A.act_id = 29803286 AND AA.aac_id
> = 1885944;
>
> con un muy buen plan de ejecución, que aprovecha índices al máximo, yo la
> ejecuto desde mi cliente (pgadmin) con los mismos id's y demora menos de 1
> segundo, y así pasa normalmente desde la aplicación tambien, pero hay
> momentos en que sucede algo y esa misma query demora varios minutos!!.
> La query tiene la particularidad que a dos columnas les hace un
> *encode*(columna, 'base64')
> y sospecho que eso puede estar causando algo raro,
> Esta query va siempre contra el servidor slave y su plan es:
> "Nested Loop Left Join (cost=0.00..18.38 rows=2 width=349) (actual
> time=0.087..0.089 rows=1 loops=1)"
> " -> Nested Loop Left Join (cost=0.00..15.62 rows=2 width=254) (actual
> time=0.070..0.071 rows=1 loops=1)"
> " Join Filter: (a.act_id = aa.act_id)"
> " -> Nested Loop Left Join (cost=0.00..12.94 rows=1 width=224)
> (actual time=0.061..0.062 rows=1 loops=1)"
> " -> Nested Loop (cost=0.00..12.66 rows=1 width=216)
> (actual time=0.055..0.056 rows=1 loops=1)"
> " -> Nested Loop (cost=0.00..10.18 rows=1 width=203)
> (actual time=0.051..0.052 rows=1 loops=1)"
> " -> Nested Loop (cost=0.00..7.03 rows=1
> width=187) (actual time=0.027..0.028 rows=1 loops=1)"
> " -> Nested Loop (cost=0.00..6.75 rows=1
> width=173) (actual time=0.023..0.023 rows=1 loops=1)"
> " -> Nested Loop (cost=0.00..6.47
> rows=1 width=178) (actual time=0.020..0.020 rows=1 loops=1)"
> " -> Index Scan using
> or_pk_act on act a (cost=0.00..3.81 rows=1 width=51) (actual
> time=0.011..0.011 rows=1 loops=1)"
> " Index Cond: (act_id =
> 30580021)"
> " -> Index Scan using
> or_rg_temp_229645822_1 on exp e (cost=0.00..2.64 rows=1 width=135) (actual
> time=0.007..0.007 rows=1 loops=1)"
> " Index Cond: ((exp_id =
> a.exp_id) AND (exp_id IS NOT NULL))"
> " -> Index Scan using or_pk_tex on
> tex te (cost=0.00..0.27 rows=1 width=11) (actual time=0.002..0.002 rows=1
> loops=1)"
> " Index Cond: (tex_id =
> e.tex_id)"
> " -> Index Scan using org_pkey on org oi
> (cost=0.00..0.27 rows=1 width=30) (actual time=0.004..0.005 rows=1
> loops=1)"
> " Index Cond: (org_id =
> e.org_idradactual)"
> " -> Index Scan using or_ix1_act_fir on act_fir
> af (cost=0.00..3.15 rows=1 width=24) (actual time=0.024..0.024 rows=1
> loops=1)"
> " Index Cond: (act_id = 30580021)"
> " -> Index Scan using or_pk_usr on usr uf
> (cost=0.00..2.47 rows=1 width=29) (actual time=0.004..0.004 rows=1
> loops=1)"
> " Index Cond: (usr_id = af.usr_id)"
> " -> Index Scan using aex_idx1 on aex ae (cost=0.00..0.27
> rows=1 width=16) (actual time=0.004..0.004 rows=0 loops=1)"
> " Index Cond: (e.exp_id = exp_idacum)"
> " -> Index Scan using or_aac_fk1 on aac aa (cost=0.00..2.65
> rows=2 width=38) (actual time=0.007..0.007 rows=1 loops=1)"
> " Index Cond: (act_id = 30580021)"
> " -> Index Scan using or_rg_temp_229645822_1 on exp ea (cost=0.00..1.35
> rows=1 width=111) (actual time=0.000..0.000 rows=0 loops=1)"
> " Index Cond: (ae.exp_id = exp_id)"
> "Total runtime: 0.207 ms"
>
> Tengo configurado en postgresql.conf que haga log de sentencias de mas de
> 6 segundos y aparece esta query demorando algunas veces mas de 20 o 30
> segundos y aun mas.
>
> Hemos revisado los ajustes del postgresql.conf y varias cosas mas y parece
> estar correcto.
>
> Para los que se animaron a leer hasta acá, tienen alguna sugerencia de que
> puedo revisar y probar?
> MUCHAS GRACIAS!
>
>
>