suponía que si!! puede tener diferentes planes para la misma query , mismos
valores? solo cambia el cliente
El lun, 17 feb 2025 a las 16:59, Carlos T. Groero Carmona (<
cton...@gmail.com>) escribió:
> 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 <
> guillermo...@gmail.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!
>>
>>
>>
