pg.ddx.io pgsql-es-ayuda@postgresql.org mailing list archive
help / color / mirror / Atom feedplan de ejecución
18+ messages / 4 participants
[nested] [flat]
* plan de ejecución
@ 2025-02-04 16:42 Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Guillermo E. Villanueva @ 2025-02-04 16:42 UTC (permalink / raw)
To: pgsql-es-ayuda
Postgresql 13
En una query como esta:
explain select
*
from
"companies"
inner join "subclients" on "subclients"."id" = "companies"."subclient_id"
inner join "temas" on "temas"."id" = "companies"."main_tema_id"
left join "domains" on "domains"."id" = "companies"."domain_id"
left join "papers" on "papers"."id" = "domains"."paper_id"
left join "tematicas" on "tematicas"."id" = "domains"."tematica_id"
left join "special_values" on "special_values"."subclient_id" = "companies".
"subclient_id"
where
"companies"."id" in (1381059542, 1380939758, 1380939757, 1380939753)
and "companies"."subclient_id" in (13579, 13580)
and companies.fulldate >= '2025-01-31 09:30' and companies.fulldate <
'2025-02-04
09:30'
and "companies"."hidden_by_contact" is null
and (
(subclients.show_3300 is not true and companies.ep_file !~ '_print3300')
or subclients.show_3300 is true
)
and "domains"."p_or_d" in ('p', 'd', 'b')
Tengo este plan de ejecución:
Nested Loop Left Join (cost=6.70..54.38 rows=1 width=5276)
-> Nested Loop Left Join (cost=2.28..45.94 rows=1 width=2707)
-> Nested Loop Left Join (cost=2.13..41.74 rows=1 width=2688)
-> Nested Loop (cost=1.71..33.80 rows=1 width=2655)
-> Nested Loop (cost=1.28..25.36 rows=1 width=1781)
-> Nested Loop (cost=0.86..16.92 rows=1
width=1673)
-> Index Scan using
companies_fulldate_subclient_id_idx on companies (cost=0.57..8.60 rows=1
width=1113)
Index Cond: ((fulldate >= '2025-01-31
09:30:00'::timestamp without time zone) AND (fulldate < '2025-02-04
09:30:00'::timestamp without time zone))
Filter: ((hidden_by_contact IS NULL)
AND (subclient_id = ANY ('{13579,13580}'::integer[])) AND (id = ANY
('{1381059542,1380939758,1380939757,1380939753}'::integer[])))
-> Index Scan using subclients2_pkey on
subclients (cost=0.29..8.31 rows=1 width=560)
Index Cond: (id =
companies.subclient_id)
Filter: (((show_3300 IS NOT TRUE) AND
((companies.ep_file)::text !~ '_print3300'::text)) OR (show_3300 IS TRUE))
-> Index Scan using temas_pkey on temas
(cost=0.42..8.44 rows=1 width=108)
Index Cond: (id = companies.main_tema_id)
-> Index Scan using domains_pkey on domains
(cost=0.42..8.44 rows=1 width=874)
Index Cond: (id = companies.domain_id)
Filter: ((p_or_d)::text = ANY ('{p,d,b}'::text[]))
-> Index Scan using papers_pkey on papers (cost=0.42..7.93
rows=1 width=33)
Index Cond: (id = domains.paper_id)
-> Index Scan using tematicas_pkey on tematicas (cost=0.14..4.16
rows=1 width=19)
Index Cond: (id = domains.tematica_id)
-> Bitmap Heap Scan on special_values (cost=4.42..8.43 rows=1
width=2569)
Recheck Cond: (subclient_id = companies.subclient_id)
-> Bitmap Index Scan on special_values_subclient_id_idx
(cost=0.00..4.42 rows=1 width=0)
Index Cond: (subclient_id = companies.subclient_id)
ya hice un ANALYZE.
La tabla companies tiene millones de filas.
La clave primaria de companies es "id"
No entiendo porque postgres no utiliza primero que nada ese índice para
reducir las filas de resultado, existe forma de forzar a que lo use? o es
correcto que no lo use?
Desde ya muchas gracias por los comentarios.
Saludos.
Guillermo
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
@ 2025-02-04 22:49 ` Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:00 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
0 siblings, 2 replies; 18+ messages in thread
From: Jairo Graterón @ 2025-02-04 22:49 UTC (permalink / raw)
To: Guillermo E. Villanueva <guillermovil@gmail.com>; +Cc: pgsql-es-ayuda
Saludos
id es de tipo int o bigint?
Prueba con esta otra forma de hacer el IN y nos comentas.
"companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
1380939753]::integer)
si es tipo bigint
"companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
1380939753]::bigint[])
El mar, 4 feb 2025 a las 12:43, Guillermo E. Villanueva (<
guillermovil@gmail.com>) escribió:
> Postgresql 13
> En una query como esta:
>
> explain select
>
> *
>
> from
>
> "companies"
>
> inner join "subclients" on "subclients"."id" = "companies"."subclient_id"
>
> inner join "temas" on "temas"."id" = "companies"."main_tema_id"
>
> left join "domains" on "domains"."id" = "companies"."domain_id"
>
> left join "papers" on "papers"."id" = "domains"."paper_id"
>
> left join "tematicas" on "tematicas"."id" = "domains"."tematica_id"
>
> left join "special_values" on "special_values"."subclient_id" =
> "companies"."subclient_id"
>
> where
>
> "companies"."id" in (1381059542, 1380939758, 1380939757, 1380939753)
>
> and "companies"."subclient_id" in (13579, 13580)
>
> and companies.fulldate >= '2025-01-31 09:30' and companies.fulldate < '2025-02-04
> 09:30'
>
> and "companies"."hidden_by_contact" is null
>
> and (
>
> (subclients.show_3300 is not true and companies.ep_file !~ '_print3300')
>
> or subclients.show_3300 is true
>
> )
>
> and "domains"."p_or_d" in ('p', 'd', 'b')
>
> Tengo este plan de ejecución:
> Nested Loop Left Join (cost=6.70..54.38 rows=1 width=5276)
> -> Nested Loop Left Join (cost=2.28..45.94 rows=1 width=2707)
> -> Nested Loop Left Join (cost=2.13..41.74 rows=1 width=2688)
> -> Nested Loop (cost=1.71..33.80 rows=1 width=2655)
> -> Nested Loop (cost=1.28..25.36 rows=1 width=1781)
> -> Nested Loop (cost=0.86..16.92 rows=1
> width=1673)
> -> Index Scan using
> companies_fulldate_subclient_id_idx on companies (cost=0.57..8.60 rows=1
> width=1113)
> Index Cond: ((fulldate >=
> '2025-01-31 09:30:00'::timestamp without time zone) AND (fulldate <
> '2025-02-04 09:30:00'::timestamp without time zone))
> Filter: ((hidden_by_contact IS
> NULL) AND (subclient_id = ANY ('{13579,13580}'::integer[])) AND (id = ANY
> ('{1381059542,1380939758,1380939757,1380939753}'::integer[])))
> -> Index Scan using subclients2_pkey on
> subclients (cost=0.29..8.31 rows=1 width=560)
> Index Cond: (id =
> companies.subclient_id)
> Filter: (((show_3300 IS NOT TRUE)
> AND ((companies.ep_file)::text !~ '_print3300'::text)) OR (show_3300 IS
> TRUE))
> -> Index Scan using temas_pkey on temas
> (cost=0.42..8.44 rows=1 width=108)
> Index Cond: (id = companies.main_tema_id)
> -> Index Scan using domains_pkey on domains
> (cost=0.42..8.44 rows=1 width=874)
> Index Cond: (id = companies.domain_id)
> Filter: ((p_or_d)::text = ANY
> ('{p,d,b}'::text[]))
> -> Index Scan using papers_pkey on papers (cost=0.42..7.93
> rows=1 width=33)
> Index Cond: (id = domains.paper_id)
> -> Index Scan using tematicas_pkey on tematicas (cost=0.14..4.16
> rows=1 width=19)
> Index Cond: (id = domains.tematica_id)
> -> Bitmap Heap Scan on special_values (cost=4.42..8.43 rows=1
> width=2569)
> Recheck Cond: (subclient_id = companies.subclient_id)
> -> Bitmap Index Scan on special_values_subclient_id_idx
> (cost=0.00..4.42 rows=1 width=0)
> Index Cond: (subclient_id = companies.subclient_id)
>
> ya hice un ANALYZE.
> La tabla companies tiene millones de filas.
> La clave primaria de companies es "id"
> No entiendo porque postgres no utiliza primero que nada ese índice para
> reducir las filas de resultado, existe forma de forzar a que lo use? o es
> correcto que no lo use?
>
>
> Desde ya muchas gracias por los comentarios.
>
> Saludos.
>
> Guillermo
>
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
@ 2025-02-05 01:33 ` Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
1 sibling, 1 reply; 18+ messages in thread
From: Horacio Miranda @ 2025-02-05 01:33 UTC (permalink / raw)
To: Jairo Graterón <jgrateron@gmail.com>; +Cc: Guillermo E. Villanueva <guillermovil@gmail.com>; pgsql-es-ayuda
--Apple-Mail-5B35C4EA-C086-452D-B901-07D1E4C11685
Content-Type: multipart/related;
type="text/html";
boundary=Apple-Mail-ABAB8549-B265-4E8F-B3F1-FEA37FFA3370
Content-Transfer-Encoding: 7bit
--Apple-Mail-ABAB8549-B265-4E8F-B3F1-FEA37FFA3370
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto">Usa depez para compartir el plan de ejecuci=
=C3=B3n por favor<div><div style=3D"display: block;" class=3D""><div style=3D=
"-webkit-user-select: all; -webkit-user-drag: element; display: inline-block=
;" class=3D"apple-rich-link" draggable=3D"true" role=3D"link" data-url=3D"ht=
tps://explain.depesz.com/"><a style=3D"border-radius:10px;font-family:-apple=
-system, Helvetica, Arial, sans-serif;display:block;-webkit-user-select:none=
;width:300px;user-select:none;-webkit-user-modify:read-only;user-modify:read=
-only;overflow:hidden;text-decoration:none;" class=3D"lp-rich-link" rel=3D"n=
ofollow" href=3D"https://explain.depesz.com/"; dir=3D"ltr" role=3D"button" dr=
aggable=3D"false" width=3D"300"><table style=3D"table-layout:fixed;border-co=
llapse:collapse;width:300px;background-color:#275376;font-family:-apple-syst=
em, Helvetica, Arial, sans-serif;" class=3D"lp-rich-link-emailBaseTable" cel=
lpadding=3D"0" cellspacing=3D"0" border=3D"0" width=3D"300"><tbody><tr><td v=
ertical-align=3D"center"><table bgcolor=3D"#275376" cellpadding=3D"0" cellsp=
acing=3D"0" width=3D"300" style=3D"table-layout:fixed;font-family:-apple-sys=
tem, Helvetica, Arial, sans-serif;background-color:rgba(39, 83, 118, 1);-app=
le-color-filter:initial;" class=3D"lp-rich-link-captionBar"><tbody><tr><td s=
tyle=3D"padding:8px 0px 8px 0px;" class=3D"lp-rich-link-captionBar-textStack=
Item"><div style=3D"max-width:100%;margin:0px 16px 0px 16px;overflow:hidden;=
" class=3D"lp-rich-link-captionBar-textStack"><div style=3D"word-wrap:break-=
word;font-weight:700;font-size:12px;overflow:hidden;text-overflow:ellipsis;t=
ext-align:left;" class=3D"lp-rich-link-captionBar-textStack-topCaption-leadi=
ng"><a rel=3D"nofollow" href=3D"https://explain.depesz.com/"; style=3D"text-d=
ecoration: none" draggable=3D"false"><font color=3D"#FFFFFF" style=3D"color:=
rgba(255, 255, 255, 1);">New explain | explain.depesz.com</font></a></div><=
div style=3D"word-wrap:break-word;font-weight:600;font-size:11px;overflow:hi=
dden;text-overflow:ellipsis;text-align:left;" class=3D"lp-rich-link-captionB=
ar-textStack-bottomCaption-leading"><a rel=3D"nofollow" href=3D"https://expl=
ain.depesz.com/" style=3D"text-decoration: none" draggable=3D"false"><font c=
olor=3D"#FFFFFF" style=3D"color: rgba(235, 235, 245, 0.6);">explain.depesz.c=
om</font></a></div></div></td><td style=3D"padding:6px 12px 6px 0px;" class=3D=
"lp-rich-link-captionBar-rightIconItem" width=3D"30"><a rel=3D"nofollow" hre=
f=3D"https://explain.depesz.com/"; draggable=3D"false"><img style=3D"pointer-=
events:none !important;display:inline-block;width:30px;height:30px;border-ra=
dius:3px;" width=3D"30" height=3D"30" draggable=3D"false" class=3D"lp-rich-l=
ink-captionBar-rightIcon" alt=3D"favicon.ico" src=3D"cid:B89A304C-731D-4B22-=
BF58-50651BC71F41"></a></td></tr></tbody></table></td></tr></tbody></table><=
/a></div></div><br><div><br></div><div>Usa esta forma </div><div>explai=
n (analyze,buffers) select ..</div><div><br></div><div><br id=3D"lineBreakAt=
BeginningOfSignature"><div dir=3D"ltr">Regards,<br><div>Horacio Miranda</div=
></div><div dir=3D"ltr"><br><blockquote type=3D"cite">On 5 Feb 2025, at 11:4=
9=E2=80=AFAM, Jairo Grater=C3=B3n <jgrateron@gmail.com> wrote:<br><br>=
</blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div d=
ir=3D"ltr">Saludos<div><br></div><div>id es de tipo int o bigint?</div><div>=
<br></div><div><div>Prueba con esta otra forma de hacer el IN y nos comentas=
.</div><div><br></div></div><div><br></div><div>"companies"."id" =3D ANY (AR=
RAY[1381059542, 1380939758, 1380939757, 1380939753]::integer)<br><br></div><=
div>si es tipo bigint</div><div><br></div><div>"companies"."id" =3D ANY (ARR=
AY[1381059542, 1380939758, 1380939757, 1380939753]::bigint[])<br><br></div><=
div><br></div></div><br><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">El mar, 4 feb 2025 a las 12:43, Guillermo=
E. Villanueva (<<a href=3D"mailto:guillermovil@gmail.com">guillermovil@g=
mail.com</a>>) escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div>Postgresql 13</div>En una query como est=
a:<div><div style=3D"padding:0px 0px 0px 2px"><div style=3D"color:rgb(0,0,0)=
;font-family:Consolas;font-size:10pt;white-space:pre-wrap"><p style=3D"margi=
n:0px"><span style=3D"color:rgb(128,0,0);font-weight:bold">explain</span> <s=
pan style=3D"color:rgb(128,0,0);font-weight:bold">select</span></p><p style=3D=
"margin:0px">*</p><p style=3D"margin:0px"><span style=3D"color:rgb(128,0,0);=
font-weight:bold">from</span></p><p style=3D"margin:0px"> <span style=
=3D"color:rgb(0,0,128);font-weight:bold">"companies"</span></p><p style=3D"m=
argin:0px"> <span style=3D"color:rgb(128,0,0);font-weight:bold">inner</=
span> <span style=3D"color:rgb(128,0,0);font-weight:bold">join</span> <span s=
tyle=3D"color:rgb(0,0,128);font-weight:bold">"subclients"</span> <span style=
=3D"color:rgb(128,0,0);font-weight:bold">on</span> <span style=3D"color:rgb(=
0,0,128);font-weight:bold">"subclients"</span>.<span style=3D"color:rgb(0,0,=
128);font-weight:bold">"id"</span> =3D <span style=3D"color:rgb(0,0,128);fon=
t-weight:bold">"companies"</span>.<span style=3D"color:rgb(0,0,128);font-wei=
ght:bold">"subclient_id"</span></p><p style=3D"margin:0px"> <span style=
=3D"color:rgb(128,0,0);font-weight:bold">inner</span> <span style=3D"color:r=
gb(128,0,0);font-weight:bold">join</span> <span style=3D"color:rgb(0,0,128);=
font-weight:bold">"temas"</span> <span style=3D"color:rgb(128,0,0);font-weig=
ht:bold">on</span> <span style=3D"color:rgb(0,0,128);font-weight:bold">"tema=
s"</span>.<span style=3D"color:rgb(0,0,128);font-weight:bold">"id"</span> =3D=
<span style=3D"color:rgb(0,0,128);font-weight:bold">"companies"</span>.<spa=
n style=3D"color:rgb(0,0,128);font-weight:bold">"main_tema_id"</span></p><p s=
tyle=3D"margin:0px"> <span style=3D"color:rgb(128,0,0);font-weight:bold"=
>left</span> <span style=3D"color:rgb(128,0,0);font-weight:bold">join</span>=
<span style=3D"color:rgb(0,0,128);font-weight:bold">"domains"</span> <span s=
tyle=3D"color:rgb(128,0,0);font-weight:bold">on</span> <span style=3D"color:=
rgb(0,0,128);font-weight:bold">"domains"</span>.<span style=3D"color:rgb(0,0=
,128);font-weight:bold">"id"</span> =3D <span style=3D"color:rgb(0,0,128);fo=
nt-weight:bold">"companies"</span>.<span style=3D"color:rgb(0,0,128);font-we=
ight:bold">"domain_id"</span></p><p style=3D"margin:0px"> <span style=
=3D"color:rgb(128,0,0);font-weight:bold">left</span> <span style=3D"color:rg=
b(128,0,0);font-weight:bold">join</span> <span style=3D"color:rgb(0,0,128);f=
ont-weight:bold">"papers"</span> <span style=3D"color:rgb(128,0,0);font-weig=
ht:bold">on</span> <span style=3D"color:rgb(0,0,128);font-weight:bold">"pape=
rs"</span>.<span style=3D"color:rgb(0,0,128);font-weight:bold">"id"</span> =3D=
<span style=3D"color:rgb(0,0,128);font-weight:bold">"domains"</span>.<span s=
tyle=3D"color:rgb(0,0,128);font-weight:bold">"paper_id"</span></p><p style=3D=
"margin:0px"> <span style=3D"color:rgb(128,0,0);font-weight:bold">left</s=
pan> <span style=3D"color:rgb(128,0,0);font-weight:bold">join</span> <span s=
tyle=3D"color:rgb(0,0,128);font-weight:bold">"tematicas"</span> <span style=3D=
"color:rgb(128,0,0);font-weight:bold">on</span> <span style=3D"color:rgb(0,0=
,128);font-weight:bold">"tematicas"</span>.<span style=3D"color:rgb(0,0,128)=
;font-weight:bold">"id"</span> =3D <span style=3D"color:rgb(0,0,128);font-we=
ight:bold">"domains"</span>.<span style=3D"color:rgb(0,0,128);font-weight:bo=
ld">"tematica_id"</span></p><p style=3D"margin:0px"> <span style=3D"colo=
r:rgb(128,0,0);font-weight:bold">left</span> <span style=3D"color:rgb(128,0,=
0);font-weight:bold">join</span> <span style=3D"color:rgb(0,0,128);font-weig=
ht:bold">"special_values"</span> <span style=3D"color:rgb(128,0,0);font-weig=
ht:bold">on</span> <span style=3D"color:rgb(0,0,128);font-weight:bold">"spec=
ial_values"</span>.<span style=3D"color:rgb(0,0,128);font-weight:bold">"subc=
lient_id"</span> =3D <span style=3D"color:rgb(0,0,128);font-weight:bold">"co=
mpanies"</span>.<span style=3D"color:rgb(0,0,128);font-weight:bold">"subclie=
nt_id"</span></p><p style=3D"margin:0px"><span style=3D"color:rgb(128,0,0);f=
ont-weight:bold">where</span></p><p style=3D"margin:0px"> <span style=
=3D"color:rgb(0,0,128);font-weight:bold">"companies"</span>.<span style=3D"c=
olor:rgb(0,0,128);font-weight:bold">"id"</span> <span style=3D"color:rgb(128=
,0,0);font-weight:bold">in</span> (<span style=3D"color:rgb(0,0,255)">138105=
9542</span>, <span style=3D"color:rgb(0,0,255)">1380939758</span>, <span sty=
le=3D"color:rgb(0,0,255)">1380939757</span>, <span style=3D"color:rgb(0,0,25=
5)">1380939753</span>)</p><p style=3D"margin:0px"> <span style=3D"colo=
r:rgb(128,0,0);font-weight:bold">and</span> <span style=3D"color:rgb(0,0,128=
);font-weight:bold">"companies"</span>.<span style=3D"color:rgb(0,0,128);fon=
t-weight:bold">"subclient_id"</span> <span style=3D"color:rgb(128,0,0);font-=
weight:bold">in</span> (<span style=3D"color:rgb(0,0,255)">13579</span>, <sp=
an style=3D"color:rgb(0,0,255)">13580</span>)</p><p style=3D"margin:0px">=
<span style=3D"color:rgb(128,0,0);font-weight:bold">and</span> companies.fu=
lldate >=3D <span style=3D"color:rgb(0,128,0)">'2025-01-31 09:30'</span> <=
span style=3D"color:rgb(128,0,0);font-weight:bold">and</span> companies.full=
date < <span style=3D"color:rgb(0,128,0)">'2025-02-04 09:30'</span></p><p=
style=3D"margin:0px"> <span style=3D"color:rgb(128,0,0);font-weight:bold"=
>and</span> <span style=3D"color:rgb(0,0,128);font-weight:bold">"companies"<=
/span>.<span style=3D"color:rgb(0,0,128);font-weight:bold">"hidden_by_contac=
t"</span> <span style=3D"color:rgb(128,0,0);font-weight:bold">is</span> <spa=
n style=3D"color:rgb(128,0,0);font-weight:bold">null</span></p><p style=3D"m=
argin:0px"> <span style=3D"color:rgb(128,0,0);font-weight:bold">and</sp=
an> (</p><p style=3D"margin:0px"> (subclients.show_33=
00 <span style=3D"color:rgb(128,0,0);font-weight:bold">is</span> <span style=
=3D"color:rgb(128,0,0);font-weight:bold">not</span> <span style=3D"color:rgb=
(128,0,0);font-weight:bold">true</span> <span style=3D"color:rgb(128,0,0);fo=
nt-weight:bold">and</span> companies.ep_file !~ <span style=3D"color:rgb(0,1=
28,0)">'_print3300'</span>)</p><p style=3D"margin:0px"> <sp=
an style=3D"color:rgb(128,0,0);font-weight:bold">or</span> subclients.show_3=
300 <span style=3D"color:rgb(128,0,0);font-weight:bold">is</span> <span styl=
e=3D"color:rgb(128,0,0);font-weight:bold">true</span></p><p style=3D"margin:=
0px"> )</p><p style=3D"margin:0px"> <span style=3D"color:rgb(12=
8,0,0);font-weight:bold">and</span> <span style=3D"color:rgb(0,0,128);font-w=
eight:bold">"domains"</span>.<span style=3D"color:rgb(0,0,128);font-weight:b=
old">"p_or_d"</span> <span style=3D"color:rgb(128,0,0);font-weight:bold">in<=
/span> (<span style=3D"color:rgb(0,128,0)">'p'</span>, <span style=3D"color:=
rgb(0,128,0)">'d'</span>, <span style=3D"color:rgb(0,128,0)">'b'</span>)</p>=
</div></div></div><div><br></div><div>Tengo este plan de ejecuci=C3=B3n:</di=
v><div>Nested Loop Left Join (cost=3D6.70..54.38 rows=3D1 width=3D5276=
)<br> -> Nested Loop Left Join (cost=3D2.28..45.94 rows=
=3D1 width=3D2707)<br> -> Nested Loop Le=
ft Join (cost=3D2.13..41.74 rows=3D1 width=3D2688)<br> &n=
bsp; -> Nested Loop (cost=3D1.71.=
.33.80 rows=3D1 width=3D2655)<br> &=
nbsp; -> Nested Loop (cost=3D1.28..25.36=
rows=3D1 width=3D1781)<br> &=
nbsp; -> Nested Loop (cost=
=3D0.86..16.92 rows=3D1 width=3D1673)<br> &=
nbsp; -=
> Index Scan using companies_fulldate_subclient_id_idx on companies=
(cost=3D0.57..8.60 rows=3D1 width=3D1113)<br> &nb=
sp; &n=
bsp; Index Cond: ((fulldate >=3D '2025-01-31 0=
9:30:00'::timestamp without time zone) AND (fulldate < '2025-02-04 09:30:=
00'::timestamp without time zone))<br> &nb=
sp; &n=
bsp; <font color=3D"#ff0000">Filter: ((hidden_by_contact IS NU=
LL) AND (subclient_id =3D ANY ('{13579,13580}'::integer[])) AND (id =3D ANY (=
'{1381059542,1380939758,1380939757,1380939753}'::integer[])))</font><br>&nbs=
p; &nb=
sp; -> Index Scan using subclients2_pke=
y on subclients (cost=3D0.29..8.31 rows=3D1 width=3D560)<br> &nb=
sp; &n=
bsp; Index Cond: (id =3D companies=
.subclient_id)<br> &n=
bsp; Fi=
lter: (((show_3300 IS NOT TRUE) AND ((companies.ep_file)::text !~ '_print330=
0'::text)) OR (show_3300 IS TRUE))<br> &nb=
sp; -> Index Scan u=
sing temas_pkey on temas (cost=3D0.42..8.44 rows=3D1 width=3D108)<br>&=
nbsp; &=
nbsp; Index Cond: (id =3D companies.main_tema_id=
)<br> -=
> Index Scan using domains_pkey on domains (cost=3D0.42..8.44=
rows=3D1 width=3D874)<br> &=
nbsp; Index Cond: (id =3D companies.domai=
n_id)<br> &nbs=
p; Filter: ((p_or_d)::text =3D ANY ('{p,d,b}'::text[]))=
<br> -> Index Scan u=
sing papers_pkey on papers (cost=3D0.42..7.93 rows=3D1 width=3D33)<br>=
Index C=
ond: (id =3D domains.paper_id)<br> -> In=
dex Scan using tematicas_pkey on tematicas (cost=3D0.14..4.16 rows=3D1=
width=3D19)<br> Index Cond:=
(id =3D domains.tematica_id)<br> -> Bitmap Heap Scan on spec=
ial_values (cost=3D4.42..8.43 rows=3D1 width=3D2569)<br> &=
nbsp; Recheck Cond: (subclient_id =3D companies.subclient_id)<br>&nbs=
p; -> Bitmap Index Scan on special_values_subc=
lient_id_idx (cost=3D0.00..4.42 rows=3D1 width=3D0)<br> &=
nbsp; Index Cond: (subclient_id =3D companies.su=
bclient_id)</div><div><br></div><div>ya hice un ANALYZE.<br>La tabla compani=
es tiene millones de filas.</div><div>La clave primaria de companies es "id"=
</div><div>No entiendo porque postgres no utiliza primero que nada ese =C3=AD=
ndice para reducir las filas de resultado, existe forma de forzar a que lo u=
se? o es correcto que no lo use?</div><div><br></div><div><br></div><div>Des=
de ya muchas gracias por los comentarios.</div><div><br></div><div>Saludos.<=
/div><div><br></div><div>Guillermo</div></div>
</blockquote></div>
</div></blockquote></div></div></body></html>=
--Apple-Mail-ABAB8549-B265-4E8F-B3F1-FEA37FFA3370
Content-Type: image/x-icon;
name=favicon.ico;
x-apple-part-url=B89A304C-731D-4B22-BF58-50651BC71F41
Content-Disposition: inline;
filename=favicon.ico
Content-Transfer-Encoding: base64
Content-Id: <B89A304C-731D-4B22-BF58-50651BC71F41>
iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAYAAACqaXHeAAAmxXpUWHRSYXcgcHJvZmlsZSB0eXBl
IGV4aWYAAHjarZxpkuW4spz/cxVaAjEDy8Foph1o+fo8wMzq7tf3mSRTlVVl5jk8JBiDh3sgmM/+
X//zPP+DP63E/MRUam45v/yJLTbf+aa+98/96t5o/9uf+L3Fz397/fl9w/NS4Gu4P+b9Hd95Pf35
QPk+4MbfX3/K/M5TvxN9b/ycMOjKnm++4+p3ouDv6+77+Wnf53r8y+18/+b4/ZD9+efPsWCMlThf
8I/fwYWX/6sOCKwgtND53/P/G/jM9723/13I/2675/fbfxjv97t/2O7t3+vh76Z43vwdkP9ho+91
l/7ddmahv67I/bny39440/869J+2O2fVc/a9ux4zlsrPd1M/t2LfcSBmjcE+lvlb+Jf4vtjfxt/K
LU48tvDm4O98XHMeax8X3XLdHbft63STJUa/feGr99MHe62G4puf5pSov+74gnvWEyremHgt8LL/
XYuz6za73nSVKy/Hkd5xMmce/Mff599e/H/5+3uicxS6zr3111asyyv0WIY8p/85Che489k0mX3t
7/OXuHn/4tiAB5OZuXKD/R33FCO5P7EVzM+B49Ibny+dXVnfCTAR104sxgU88GYXksvuLd4X57Bj
xT+dlfsQ/cADLiW/3HPwTQgZ51Sva/OZ4uxYn/x9GWjBESnkUHANCYSzYkzET4mVGOoppPiklHIq
qaaWeg455pRzLlkY1UsosaSSSym1tNJrqLGmmmuptbbam28BCEstt/K02lrrnYt2Tt35dOeI3ocf
YcSRRh5l1NFGn4TPjDPNPMuss82+/AqL9F95lWfV1VbfbhNKO+608y677rb7IdZOOPGkk0859bTT
f732efXvXnP/8Nx/7zX3eU0ei3Zc+eM1Xi7l5xROcJLkMzzmo8PjRR4goL189lYXo5fn5LO3eZIi
ebzmkpyznDyGB+N2Ph3367s/nvtv/fak+H/lN/+fPPfIdf8/PPfIdZ/n/qvf/sVrq1tFCeYgZaFs
+oYDsB1A3dfuB1D16pte10yHOxnllNLm5iy9BSzeU/G7hdqr23tkXZh3Fy/Fh7WFM0qY+6xDVjfH
qhY4upZOsWbh071xLG+GvdYu5cwU1wg530+UlwOf0PRDz21ToHZOulisq2N3dwZvzjLsiBXn2Sve
o8PhVou+T33sFkd+Dll8clmcnIKxuSS43oqfRR/rKxPGg3Oe4OySsyVwf+5eGke2RPiPd6XycIg+
xCFu6/89Uuyj171ZwB5Or73+e6fgoaD6csLIdtq4j6v67ukl2hXG20+hwgDaYdrNYOCR85z2gVEz
GM8VV4gn98ByCuEyieYdsNr7HC4E2LV+YuDzZNbJytazfU/rDAKAE6mkT1mN7yPL2pyY+5mOMzd8
d+R+AizMdYh++8gsXOMuN9fTOTwQizL2wk1jEaaOuOLO5rBP4Fdi9onxvBgnb+Lt7JZ2LC0QQDs1
zLRL2Dss30brjvTwY6zD7Za9z/V3JgHcItfCfzU2gcgZzwgrF8KLaOyy8eaWifIbLImY7Zi9cpiZ
Hfe3lX+cnuT0eRRQsycXy+w6aHU+H68Lfi/njr2MzbQO9/C6+RXOdN6DmziVz63hrBXsoycLH/Kp
OZCGxFttY8vuygBdpi0350MWdwIrspx/idpaVhwdi/zj5pcLvDffTHaRlFoRNWeu1nRjTrblFm++
gCPyr32UYGJ1EIqx82nNfLGCvHsNPk9/WNYGX7SqvIhJM/651+/kRgKucOjamfzlzsdebuTlB1YG
7vYZukqgQE4LNUpG6dzfjA5ECme58pvOWCt3fg6vmaEeV2ZIZj+O/U0RrHsWkJgjNz6VBXAwFrZv
UKQ9tm7IFS3p9Hcrm7utOQP6hJSv67THHBi0pt3u21jneHB5HhdAzZYGoFrcwKzbQb2oHlxn9BvV
LIzoP8BILPLNCHpvNaJ+dRn91DIStK+vTUEUEHkLjLKTsBPTUwEU+nrzPSBksoLBERO/CWFxITgY
dEBK4y0h7c7SHAlNegQZWRDZBgm3r7dJ5+dz98HCq1BSyOYyAoYIZeIP0pT7ohoIpgBeqh6lgnLX
exrAbhssjlo1nxzGSqOPuDfJnarQv3ZId0wiPgcAmW1hNW6X67GQ8XpqwFj84cwHIloGJKJ3fEks
pyBIw0AGDQQuNiHTvIyxCiUycOk1HMa3sHj53GvOoWgXjG3sgMUThASCDIoRMRJOOmdETFUIQl4i
hSvJMCgls51dG7ffzhdNPT/2EVLGndTngjMXinZfFOcx/JoDrMyedE0kCZhS/thshi1eHlll+hCy
cY+shMDjUhP3Uh+TPlOADjxoybj9l4q6rQ4gQfo9B4NLbYbwcF+NNOmgHGUj/KU+jC/4u+ogrkrc
lFcezhuMO0aDoIxUAGoxtouZwCeSoLPYYcxhlaM7xeWJq9wCyZUz8UWaAr9CpfwDiGDVeYibDNPo
sBNOWSAAOD0K4DrEgshrWFE1JVK2QYYLtqtChEKGMOonYdIjBwTVcZIN/qLidXTNlfZb0q6wAMrD
LMtuBzcCnFb1b9GE0fIR7PgcTJNyXQKTXWLy3IOPpH4nIbgGkWVekeo9CvqvaFFEJsnA2w047fUh
lvxRfHTzr1nHgRikD2dbmcyaCSvjCeByEGhAE7dRzCXYR9GzA9lvEQRiLMj9+0HwxYEgCym/9+JO
lWH4pA8cKNhOCC/uobQuOOTWBhXRlk4BVHDepav8WTHIfsBaQEWv9GEZ0FPMb2lCjjcV1Rpiekqe
uUUfhg+VupPht6v1CEHali5mUju5ALd1pajFB2cVjq4PDB8CvMKVEtEFX4Z6+uOug29JIjAD5QiU
nQR6/qkb8D3uX/UXhq4UeKZCK6okWa2VTYT6OcAWptjt5CLeefIW1n3IEUzPRSKLgdoGAaYs8yiD
iInIMV0ZRzgvZZzdDALYklrLobouBUPfOJ8sZ5E7i0xQkljv41httY9VasmClxchuuq6ChGJwDpJ
6GWpYAvWZXBboAQHaDk8KJREpXWJuo8j6w5dJYdIo4oKR7HPdsJuPkggd3wtznuux9IYxuGIduol
2e+PRZsKSDFEp6Cyyo4TYA94oQQSNu42iPo8wD0wD4oTVEa/G3P7sRtDISwVSLguuQl4NziYSnaH
2USVZONJOCU4K/xCNoOudDBau8AGR4ekYT1y9TTcC1k/CvygRBGTOIXYJ26Gaoy7zARsh92I5uCE
oSqCEqFWEodxetQM0Q5EYWPW5ibfnbA/ho3M5kSXYFDbxG6oAPOy/yeTVSVfypTxidzZ0kyJEou6
gmuLcC3FBMmhNXFPv2vC9tnWtB7dA4uS4iD0iBwKPPaYPiTVyqNYwjFKtKkQII7tyqo6VddNBerl
WBEabzdKXixuIQJfRBrsYquEi+8MpZil2ZqTaH9TFqGXRiJ6WV7lPaTGU2cy+jhKXEYHiHxolWGY
6pfROM6mmIbcUaYCgQADIhf2lKCj3HCvTyPjYB6XxpE6I3GdPnJXdBc4PfyRFXgK/HGXfhg8ceBx
7xGEvYQVwIZyKUYycUQdRBWMEGYvrOt7SHvGnRHELlG0d3qvSBxUo/ttfe3rwzeYNUbTf4oZQQhG
TZZff9d/o29yqwoblPIXnckflrqeP+DcIlSaZMWHQ35SqQWT+MSlmUTOIQ4AGcpfEjG2kMncE+Z/
Vtv5cliVlWb3P5VGkDQWVesmNvamVpDiGSoGlcUmXUzHMHcLEjIIiVKAtHW8WudHjvzf7v4vXwPU
mAjb4onu0qBX+MlZn+OXWVgKSfhJ7BKUVXQT8mkRU65i+grivp6TZhqocmhamG/ZjzeKAD/ZFQJn
csCDlERS7gDUiqImHApEBzAFtRur9O2WzM9nLqESt/9AsKlUYRrKnstElGPc65T9hLLBgrIoKMHx
LaKQYgqVWEdmhvJSkZ5rFrjOXO+CIhCBJicVnBmKW0WMrHhYcFEglbmAJrrcX8QMg9t9fqAf1YZv
yVidSn4Ry9K9Bt366TtCiV3QbS01ZEbym3qSXwIicjvEEfdKuKj4iurWcCWtZUuGQUFEu6Q7KMnl
RRWKGYYVZFU7qg9GISB3sXXM8sLVcqA+DqVUuCvElYCu6rrkPuRTJzFvzit6mrIzILOqWVMArhzQ
MRxlhbrGppIswkb8efzuqL9LHRcYwgW3HM8UPCFqsBlhBaMOpSu51Nb9Ql9ZR46Db0BU7VgSqpuw
CAZq4OcXv6tOaP6jb2EfLVnsC6IG2jaqigIjDYdl/KUWCwkkgdixpDV9xnsvKD0yVPuRfxbcrBXc
2Nikcm+Bj08jUdKfkhm4RXxLuYE9FlAo8S/GSOQiahbiMlnnqptGKSp7VsWNlcDCOC1hTE4CcyBu
q7WOFpAq690tU0llv4fzqi9FEYPHC2yTEDpI6xHwWz6NwvcW1G+ZA67K8ogSqJNXOhIXYi+mIKUB
1evZ3cO1sd7uWe0HZB/eUUFaxipBUBzD9Zf8S1AMxRdXDp444iKJ4ksCKZEE9AGkAe1IF25WFw4G
XlJIhAk502KA1BGmINC42gXdP2scEutYggubcMTsqXd4ALBFdqzsSVQwDkX5loXroSsbGKeUVUBt
VIiYhF9KnGuvK0GNFwLxulFEq5mJIN/csTAq690jHg/rhuiraSHKfp7srNcjJo3WhwcF8cVNWhOu
Q60pS74hsai1lUqukToC9mzVx7jYenS8gdmx44d1qEgfCKqfotzq34DP53KsbTyFnFhCyKa+LqwD
GvSEIHm2UL59s+IPrgdYXIWjLNU2H9p7C5XCGdVAsTpWI0laL1kynmS8cMqquDm7qjIt3XC1reMW
1e9oVzKA/KpjBJQh+PJyPaVrhwd0UDjgkaDmmKLfg3/IDWUzaL1HRTW5SnajrRpLXW9rCjG1Y1CH
1lCj9qsFpkQDbgQYlymBaWNCq5XJSA11e0HRLKYzlLB3dVFoe/QuJIIMW7D+8lZpiWNIpHYa58vL
bi+TlASriIqv03qFmdpOKT8mCg2D5gPM7MrNyRgrJ+z/mTuFv9TJKqrljAqL61GR/JFWrCEYNTgL
TZsEWYeYxKRidjAiEsT6pQcu7J1KqZmfq28fSCdpd+JNZiRgqFzaYMnNOuESLJQtAg/2SHIBs3Zj
Sk8iBulMcN6sOzfrEqBJpvjlZ8XYED6wfq4kpKIcLl9uo/e9jbkVa4n2PXiJ46thNWqDtBmEvkr0
14c0894eH4nkRYBx69f3/OllcxeS4MkBn6+JZ25TTWtjh+Uk6f6EkdFeKsjlFgUVTzKxT6+WNpVl
bXEwyw70BZA0c1rIjIQ8qB2u0593YUbODO4JurQe7ic5hAEuYl1mqf3yFsW3Q5B8yZnKiRT3YMt0
o2N8cg3K2I4R5wxNL9YlJke2Kdr5XqdQRIRDzQFI2iex7hL+TgJmY+BEdlZGqCdJhgJ3vFucepJZ
h1in0Y446vcBJA0xuaShgRpAZn+9wQe4VjMR8Pjk4DZyKZ3Vq2oh3Ac5Cu711LyPqBy1c5Pg5TpE
enGMx2Ej4k2qkhtUq1qXVmNjiOV6KusxwYF4AMjK1OYGwWlcTH5t4hItWRUZ8gOATyIQRLl1ASCH
8rmr614jKBSo3bEVKQ8NlXCpqDagpLGoZyEuJC86CDxADG3PAGnmc+u4BUULnxKHgWahOAdGIvgp
R06Sk2gHYR5MgNuD6tMEh0uulDX4LR+hGE01v4ATLCUQ5m6Hmh1zfQ0u8Rg/HAmJqCEcF+tVG0CS
SC2gMq76lz9ApiqFG6rDIx5ikoi7M/OA+UNPLr3xj2lo1s7yxMfMX6IGHAjjdrJXjbcVNrHfz7Eq
RD+0Wrt54anuqPucIrBHEA8PEIiUmcdJddDVLa2wcnv4N6jLasG3LmNf/bywv2cbZnuY3/bEaSkf
rqHP8x9gu50bqqVE2aDAUle2u6AMb+ccDxxmO5YjIgIxgZTWX0hj+ZDtS6gm+p9UmlHFX1s/rdlO
GnVRbQJyTdaYMBTWSaiqzzMrUq5Y1KoS3cKEhXE9JQWyAZAtRYsHChp4Icr9qEkJ8VihNjVTXnUW
Z10uRhLtrbPPDEbtbJtb6kxqgwd+AWBSDIuVKdXcB1dJKwEYsAawQ0pG709qy4gZ4U7whQZijBGp
elN6a0vYQxi5aG0GAe0RU1dPQ2CWxTvgM8gz5CpXfZc1uNUfBDqISfJVUUkVUkdMGz+zqWbUDWZX
00HQDDWuFfFFXUjgxiFuwAwCoc8YQMTd3hsYeE4yHh4ItJWoDUNpEcXVMttAMepu0CJ1LGMTCamQ
Bdtg0K5tX/Jrun01d759m5QBQxASDLj9MFYbPZyudReosj41wA2sO6Zuhhrp2r8a/nZFh/UKi7aZ
qF0PziUcSnUgyJZEUUcBVu2ouWJTzboJS8J3oNmEJpBkwc5qxPCJZA36rDwhNuEv6heZ2Vf3SZsb
t39MwZnqhJxafiozHIDMBnPVjEqSryLIwuygYn5bQFm7FTLVLBP6+Zpm154eaw6iKd5OaeoN9+Xq
V7bWLYFIrikrtMmsMtTKEAWqomQqLKWHmqpqAJ6qmSJtqkFNUy44QmqnF2KzTCnIsKRX8wD6gkTp
8vFAa2cEh9SOkLCHsIuqdLV4BXhLqszhY++GQHt1NTSXFBFgShp3CKuaGGqjNXGOqHgr1equBC+F
pd9i3kxB/rRg5lM/0OSuh24MIa7KL2BSG/72Ac8FZAjUQg6K6IMNiHk4SkCqqAXxwGm9s+81/bS/
XYaa1UMbOsEFFVIrqVX/kv135/GHR4mlkqNPqvufuCPELa9OdTcOBWZAI0g4QUncLL52DEez/Ejq
wI+SENXFngTU3I9uYWqXwVB2rZg0WgFlaK0kT2rDbMjmpIZKIiiLiZidH6kYip74/bcLYnzpt6Z3
GFhzEmGgHvaWUC01frJEDGCZLHms0VnvbvPdcutoS28JFbRTuQWrnXgJEQpDECscijaIRFgL14DF
xvxwAHlL3r8w36QtbZG13FtukfjxlHovAA7UzJqBFsrIMBupAu6f9PHQY2CVhOsjvBFdXQRnfkJR
tFGsBBOuipaITo8tpNDQRtdes46DJUuLP6t3V4mcKfJnd6KmX8tqbCN+u7ZkoFlDO6zHPNaGgPpi
ZK4q/ooDRE0K73mTEpvaQshf+bLCbSTIE9v6zzD0eYkkxYOCDxyzXtB4CJCepB0DpZvKxGUyWYxh
qruvRg+BAQNp6jqveSWddZThuhDtHqXbj4BtKM9D2ALIoosT+wCj9yTDbOp/RnyxBFoSemtJnUm6
WueaLBt22ce6+FtKldxd1AUsp104BCOWJMEVp0GSV58Teq32008s1k+cnQpdn2UWoeqKbHyiNwm3
nMUWBVmhpTDaHv6+bj+jaYNKLdoLwnPE56/QeLSNpP4KQasaWQBHqlkhkMhbYsoRE9x9UkktIanN
kVBn0aX0eLz2W1zT6BmKAjQSWRXZqQ4WFoo/W+Rki7rA4r/aQP7YFPlLXVNbpfaR091Fy/FcNA16
Q10KEg4PZUtpkwj66LSduvpJc8AGnq3iQ11Z1r4SjfqKhzEii/911FRtPXhVGm1Vca7oYPwglzgU
JOg5/tt1fqXO87Gd+EuWlMVdOpdo8hgcQ1V0ZZE87Me6xVE7VYWqcR4HQQo2gwHmeiFzrVEbwvjc
sOmbxLDu2O2dRe08qaJdXTtM1z4IX4mcM18ORHz/kbTkiNpgnKpoR0a9iqDYK+odrp8OGBRuUufL
A6MUyxRVES58AkLUVf34nog1bb04taWOQrBI+aJDrft26iqw7LD203pVtwuuR12AIKZkEgpAcdW+
jeDk/eoUs+/Csj89XdFe7CLmKCkqx2BSHDOhMfWgGxS+2s1UV9241XS2hJsUTvMX2l1ozWJK2zXU
/vzJqrsXVQbmTbf6qVkzbd9fiHIb2VTrqIYCqdc7ELpcU/0hIBc+2GppTe2uo7qSqEgo1Tbkh6Bw
Qi1d/tTW+FGbuIBQkicD1O2xnVuIekWtaNTW2rkBeTJUpxOBj1lGrLK39gC34uZoMqHqLsxWkk0P
ITpeNUHAGG7V9mhsluVvnGhwrWUppC1A6zcjTNT21L4LiTAoR3c3A6KGHgHkY6pSEk2zCGE6sfhS
a7AKrk2Z5e6sxF5Wh/2yduAGsy/gBD/eOmAWIfyFRYMUTUq1Xi8Xq35aV8d0b3BptpfasGd7kIN+
XfXt2k/kOBRgtfjU7WXwfKsJppnBcbWWWu9ULCN72svZz7G2H/dJuXH57mOrTgWrN0apyV3+YRHY
USWurNAIHqr1vJZKn3vIxhCo2ZMT9pJNjuES40VWRy0SpXzAUGtG5QzQCrY0eWH9V6GtNjMloZdN
xUC5d19YN0SSdhJxkL8G9BiByjW+CTdYmmg77DdNRtkm1xUU4waF9iz2q6YvFNZTKKYiC9payUkM
0wMp6QRwgvF2akPUSEo+tiessaFsKWWxYykFO3oVvannbMdSW3RxdTcJonk3jj+fO9SRdoqyQuT8
7BSx+vW7U3SHGqxfq3sKmh6dKJ0YPVEOaRrCr7YfUVrNb42riQkfdFAs3nHjlhz9T3KMn+Qof00O
dUN8eAB124Oy7oDkUJbD7jDER3R7j8vfRuJWj0RbQuH2djWQakkdnrhsH7kVU5lQ3neoe0dwQ3T2
xmHOuf8MdpgRjJlWssfXd9X4y5X8EIfAi8V2rxqKkvS74w2W19ZB+LM5dVyfG+YfELQ5aOp3R/k0
Zm0/QLPCLfHaOrfhwzvAhDGp3uRBMhzlos1aOs+xiYmq847gorrd2mxQnn0NEm1pJBQLK1AH4Vgr
gvQ2q9pADM6Gse2i6WGI7OluVw3fwndHb3WpoMRo0yv5TtlFzUqpqL26uBrXBNc6Dib3qIX700I5
0Ge5TW0j7b9oQdRyjXeqI5ccNfBuT+Fxm68augSq3nLtwITFdMUvoSGHsFbvdmIyTfb+HYoAIlKF
2NDwMO58Kx4I2b3Pnn+HskIBQCPFwc2mHGP4abu0+ksScqxqropRJqSz05ai8EjF9mgH1rohQslP
mu7Lv6gA6OYdjDDeRp62yNS6SBgEKgDqPi5KwtmYiBqyxaD//GzPX+xHq3b5CjG6/W0ARVVQRYBT
O5oS/dxJH0G4mnJS6DZQ8RZRJm2UA/Mz3Xk1Te3hfiSJmivjpnIPr0YzHk8R8121BbZuNqCcX3N0
DYoXKzlzfd2T3F5H4tVQUvgGZySTdnl0jb80zO5mLCojaAPPzIlEJhHe2758TSFo9/loUM02MA01
nt+xg6GBgu3bjT5tQWpS7irfb6C7fx3Dpb6MChg0nlheoH16XM/EAwUAZp5kT6ug3mZWne0cqqsC
8mu7WDqUYHmHESaJF5+dqgRshHAMX0vTxhFhKk1P1tiU6h0YzndQ1Yj5+YaDJAgwAgt7IVXLIhud
4I/NGMWh2FbPQ2PVaXBW2868tPnO1aSunkLJCueNQC+jR/UDHriCeJBS2Zv8N56KMTMMx0SdKi36
Nw7z07KqdzfM24dJmOw8AGmAjmvybSz1RjX3ph2w/TNZEWyyIpOaiAnUNnS7g+qgh4bGqNjkSd5G
tKaRIg1R4Up0BWR2iTx9nYXg3r8CLKUp/EyraDsfebrnfP7WB0fXL/DID/hpqW+YMdl2wp1QGFI7
PzN+3RBpqQfDefz7ZO3CLH9j1KaUpFG5FGDwWycS8QHRFOEXu5Y+vRvnTQ07IuQVY/PdqEYjPU7U
uG/m3RzF6dEoQiaM7PzdQlTbzikyJP+0i52XzdcujTHaLvE6Vk/yUqdL7U5vY5Mq+upsJc9VFfQa
YdkNu2joTSf6xgHVz04sEEsNi2IbVrrDkurT9PHCx7IUJnRknG/qP+jRBriKzzaNjwx+tEPMnVH8
qF3bhpKJ2p+hPAsTatjQTpWGzNGADWJH8L9NDNnmmTVS+6iHm+7kg9a/+qtxpNvwmT7gS/XTTVRf
9j9lcAkvAhasF0UBYzPqSHN8MTZX+jf5UZFzXgVD+aVEhADA95MejixTUxPpu4yzAc1dNVbdfgYi
/SpZUzcCyZ+ZL42waoYh2my3jWfGy0LPT9yDzkZCH6fDgznB+r3asJU8l8thTvtioKLVAtEjW03Q
R2GBNfbuyN6ToxLJt1GDpmeyPWvV5ot+9RBViRw89tq0jPavtXuQ5237+vlJXjuR6ujsL1cqd/dP
6hXiSo5plEwNMbtK8D6pQ6EBCe2iri2do4HG/DMM324nXsFl5WFZeei18HEV8vx+B3epR+uOz2Fj
4jKo5m0I+aeCGRpJU1m843a1aTpmG3P73XUP3677LJogMb1ZAHptta2tWb4HlsctVQXi8BoBTTaG
tK4GsL4DqYVcAtxzFU1U6Jj3PhV193yfW0qJhnfqMQDJhGIDIDYamC04TEVQAfLvIKym89QcI5BZ
H07I4FG3fS1LQBvKU38QtqepbY1rLL/meXkV/uUUUF4cXHP1zoLGLjLHY+vSwwLir9zvHVSzUviN
qp1/GyRuUTMF5Gz7JpOfqY2UvL+snndUVZvLcaUCrCrJLtxf4PgZHJco1+VrbqT4cQ+KIug5xbHW
u/T4oC3+P330QDJrCjbJZnMh7Wu9D21nDOkieFVWr2r8jHKqb0pS/ZcxvZX1IJz2/E9bf1jKo26H
0ZQp4o8ELi6IkR6v51VDzNF6mKj0afuT9xEhEus2EjU64DQ78GiASYMAVU+rNZsuNZNqEM8K5QI6
bUNrkd+C0PC1YTjqLxtwD1Be1TsX/it8bDMPG4my2D2vryHuyn02wWZLg8at1HBbABLVu5NrJ6Fl
4WdLDO4+TnKng7Rtpp2JpRG0svSwtJjw+pnw1Li+Ozauj9WfHYPtpxdNEkSvXedEEce3bkGC54Se
6IHXrXG/YU/YCcFBAOSGJhy+jdQn/E0oYD6NLwlvrDNgo4QOgNKzNENUR9TrROv/TltNujTisZnD
BiwgG6j1kGq8N+XjTdIq0/SIXPD3kQk++NoUCRVjRduq1cQJZOnJFjUxf7OzNood7+hs+APeW/KB
TN/ajBYFAj6nzdKJfGFAbNSwpgi0Nstzsx3d22fRLKoN82uXuRGynpDuTY9wEnZ3XKVrdp+VoCAF
WEeNAezCXV4s1vSgWHcR6xZTGumdTns2w0iD05Dt0PyI15rUe3o0EDV0iVWT/9EdYOdPrNlwxKc7
mn9vz3foUS97wE4j8WKZ/rHGLHq7xQwGacf+Jg1S3iZg1CQ/zrsrmzXydLTVK+uQlopWTZav+lwG
rSpV72ACaQ2lilA2V78pg62BUT0tdZ+CMX2Kkhsa3UUGY5egARQZ5zVxP2MVthhe68pfr3EY0RAd
obLoFGvdZwVsugz11nExeLTFwty68yJDfpt6iO8YWyXE30l8axh84D0942LqiBqgEzk17kW7nlul
8h02/2XU5qm4YV7wcUqXDorq6dpg1XA/na1XjG5po/1Rw+Tb410pURT1KID16u/DC+dfHl7Avy2G
/ArFNGOpjcnn7XfoxY6bV73pUdBjewSUfAD+lk1NpKxLQUv5nq5kQS+akfPp2axW74hQ/MY3CZh0
n+kL8v6tEioSfx74tB3i+UUAJojrOXr0wEGs9Fyg09SsbZge7Qbvn+cz/7Qbf7qNQ41viEeQ7NEK
nmHwiU+zF+Frweq9yUF5kzIu1Wk9GXAHwp/VefAm7qHUusJClQw9Bvu2qLDv2iDMHW4chYBi0EP9
Lpt/sGoxIAav4BVHqLtjrGPcYafH3lSPTrMSVZrvfsh9HZ5EgNe/9HhOIZqsuaKpeduM86oujwA+
wjagKOpj2gHvd4AmBgnSuWA6W79kQXBzRAUyjipFUCOTaIrqyecvw3jqNyevNPX/eDJUohogwrjr
toOulVB35sfiubX56gGxg03niT557sWmNLbtaWdr6pLhmiseBZUFd/aUANYJ6ZVkvRxSQ5JHQ33L
aahGgrHBqbWf6lhb/lfJ9i9fnz8vULKcOpBghLfO71tMq0nmUx300FBVI0ejtH461CTejrbjuuR+
8Uw91zzvHKGFwCGwXtUh7dRg93FpT41N06Y2DH00oBioU/G1pxsfbW5bd3Svb6anpSk/44wUoo0d
2ei5pr/1JlUgbbUHLFiAP6ptzO657VztYv7ujGNyDupgW7FpYj1xeEcCII4SBV0tKiTODtZ0MfTW
49Q4daaxHFoovHWo3Y0x9MSChEPTvK6ybNzeEW7rU2MW9+FRoBAG+a6naqxi3+VgmN91/d9+ff7x
QkhDTdX3zFcznt266sG4ls0/Wniq3+/AQRVrRLK1BfXM8SUZYWmkpTTQfUW/36Lf5ZCsHb8Uq8Ih
4QFakwo+0OjEeqTS2RwVHFKPlWqfMN+NwgDkHhtA0LZ+JqU1LPQ1a9/8u3RqPGBrz3nYpjQr0mB5
EVyAAKZJRLGN0gQ4jyRrUnuEW4r2iND4priyBgSVZ3rOCVFDLl2APVrs0hM19jzQ3fG0fqaqiTrq
s0nkvshVp5nF2olvtVskatFrmZJZ4v1dAtqA6urtLOq/fqPEQG58fKC2//T0h74+/+mNf//aQtQG
oD0uIRdZ90f7s+SaVPSZmXjtrtdICmImmU/P6PQUp5poyWnuJEcQWJNowr6hnn+5TWTByN20Cl/j
knzTHgXZ5NvXuLy62BjUsSdQ/sagvr5l9g/prJr+wyO6PVJ+vke38rdnKfTKECjsJFmR4UHory4u
8oY/kyyKjTg0XJH3trsy+fIi3E7V74ZItnGkatv2ffZXjwGXoCdd1E1esc6HMGv4pSClqWHQBwBK
TxZFE1g2tP3PVjg/QdltYEbtlFd7BZAIEWc9xXH398muO9UOsvv927xQNmlzwX9PrRVj2D9PrGUN
wwPdGnHQMx239+K1I24PE93hYAxPysatwX5cRzjWmGdqVRi/bZ4IOt9ZUQzh/zyQ/uPX5x8vwE83
FmcB/Og1Dpay2UHx5+4T1MX2+U1w38EF+Hd99KxsuPD/O7RcoTXLEN8k9P563YJvPDoupRjN29SD
zbGsToHcuP6oV/A7kTN7oghQdZIepYzaCwsak9XIZms/neCWi00HOw3/zKffJ55tdvvnVzgMiJiV
x3SbivsO6YloahcH3SQI1ANPSdM/Hlkfn9u0ifHGWdMvIOjJTY6uQaihX60RhYI53K0s9Sj/upXV
4J3E+2PSO5dP8ezz9fWtMzJMNOs3egQzatAvzZC2nuqf6GEMtE0gb1nqs65djGV77bwWjTh6qqfw
GVWUbL+w6ldB/ewXFtsvbGIL+7IFav+ExmBWkiMUDd8aOMf//ASbnh56/jfdpy8H2ss7HQAAAAZi
S0dEAAwADAANSxjTpwAAAAlwSFlzAAABlgAAAZYBofSv5QAAAAd0SU1FB+MMAwsWEIY7yzEAABUV
SURBVHja3ZtrdFXlmYCffT33S845yckNEiAEEi8JRBTkIgoWKwJKVyvTzjDo6rTVwdo6tTOdNWO1
/tCFdFi2M7WdWrUytZYKgihqxRFQIRAIEcJFQyAEciGXc3I598ve8+OEAyEJJId2dTHvr6yc79v7
289+3++9fVvIK63SGavoOpqmATogIIgigiCM7RKahpZMoOka6DoIAqIgIogSoiQBkIzHiEXDJGJR
YtEQWiKOFo+iawkQRCTVhKQYkGQV1WBEMZiQVcOY1iGPZlAyEScWCRENBYiF+knGgkPGiLKKYrKj
miwoqhFZNSDJyqAx8ViESKCPSLCXRLhvxPsJkowoqSRjofT/srOz8XgKcLvdGI1GQqEQfr8fn89H
R0crIT31HiXFhDkrB5PNiSTJVwcgEY8R6Oki7G8DwGw2c3NVBUVFRRQUFCDLMolEgo6ODtra2qiv
r6e9/XR6vqSYMDk8KAYTAX8H8VAPABMnTmTu3PsoLi7G4XBgsVjw+/10dXXR2NjI/v37KSoqYtGi
RcyaNYuKigo8Hs+I6+zt7WX//v289957bNy4kVOnTtHf2YzFVYA1y4MoSiPDHskEgr0++s6dQhRF
7r//flatWsW8efMwGo2XJdra2kptbS379u1j27Zt1NbWous6VquVBx98kEceeYSSkpIxqWmHv58T
rT58fSH6QhFCkThmo4rDYsBhMVFS4CLXZR+wTp23336bZ555hj179iDKKs7cCRjM1tEB0HWdvq42
Qv425syZw69+9SvKy8sBON3uY/8XLZzt7KWjJ0BS0xEFAZfdRI7TSmlhNlPHe3BazYOA1NTUMHPm
TLxeL/FEkr3HzlDb0EJjazeBcJRYPInFpOKymZmQ5+KWsnGUF3mRJRGA3UdO899v76X+VPuIkLxZ
NuZXTmTprWVMGZeDruu88sorPP7443R3d2PzFmN1uK8MoM93jmDXWVatWsUvf/lLFFXlTzVf8NJ7
+znZ2j2qN5bnsjG9tJB5N05g7g3FqIqMruv8z/aD/G77Qbp6g1e8hsmgcFvFRO6/vYIbJuSi67Dp
48P8bNOnBCOxy86dWT6ex746l4l5bk6fPs2SJUs4fPgwFncBdnfuyACioQC+s5+zdOlSNm/eTDAS
419ffI/dR06TiTz45Rk8vGwWfcEIT//Ph3x0sDGj68wqL+LxFbcxPsdJc0cPP3jhbU62+S47R5El
Hlo6k5VfqqK/P8DixXfz8ccfY8spwur0DAWg6xodJ+vJz/NSV1eHze7gm2vf4OjpjowX/fwjS+nq
DfLtn27iTGcPVyMGRebRr8zma/MrCEZifP+/tlLb0HLFeYtnlvHEygX09fYxd+4cjhw5gnt8Gaox
ZabixW9fS8Z58skncbvd/Ofm3Rk/vNmg8MTKhei6zo9+/e5VPzxANJ5gzes7eXr9hxhVmedXL2Va
Sf4V571TfYxnX9tBVpaTzZs3YzAY6DnXfMF9n/8j4O/A6XSyYsUK2n19vP7RZxkvduWXqsh2Wvjd
9jo+a2zjzylbPj3Cv/3mfVRFYu1D9zA+x3nFOW9+Us/GXYcpKSnha1/7GslokEQsegFAMh4jHurl
G9/4BhaLhTc/OYKm6Rm//ftvr6A3GOE32/bxl5APDjTw0w27cFiMPPutu1Fk6YpzNn9yBIA77rhj
ICi7CEAintpVZ8+eDcCHtScyXtyiGVOwmQ1s/uTIFXfrq5ENOw7x7r7PKS308OCXZ1xx/NmuXgBy
c3MHQvHkBQDxWASAadOmEY7GaD6Xuc3Oq5gAwNY9R/lLy3N/2ElXb5AH7rqJ0nHZlx0bCEeJJ5Lk
5OSkwvtk4iIAkTAmk4nJkyfT2OpD0/WMd+oZU8ZxtrOXpnb/XxxAXzDCs7/fgSyJrF5265XyNzRd
R1XVQRogA2jJOG6nE0mS6BxFkDKSVE0pwKjKfFrfhJaIETjXRMTfTjzgJx4NksoXJVSrE4PTg9U7
EdWadZmMMUF/ayPh7lbioR6SsQigI8oGZLMdgzWLPwV6OLyoiluvL+K6Yi9Hms4Ney2LUcWgyLS3
p6JJcSBRks/HAIqiDKiGljGAPIvAgQMHePXV39O8exdaIj7suLAvRNjXSk9TPdacYmwFpaDrJML9
CLKKwe4m2NlM7+l6ktHw0Ow0FiUe6iPcdZae5iM89L1Gnv7eKu4oHxmA25Hy+yMA0NMAEhkC6Dt7
nG0n3uXguzYOHT095OFlWSKZ1NAvNi9NI9B+kkD7yTHfz2IyYFJlFFmiq+Uk657/OQLQ3hIit+ru
obmC03oJAOmidFjXEUXxquzR6PRyV8UUjhzcSzgax2Y24s2y4nGYMRtURFFA03V6+sOcaO2mLxgZ
7D6zx2PNLSYRDeP7ombE+2Q7LZQUeLAY1SG/VVRUkCzQaU8OnVdW5AXgs89S8c35WoV4vphxnkyO
05oRANWaxQMPPoDN7qRyUj63lI2jODcLs1ElHI3j6wsRisRx2c3cVFpIls18icEnseZOQjXZRjYx
t52KSfmYDAqdPUEaW7s53tzJiZZugpEYM2bMwJo7Ydi51xWnANTUpODKinpBA2TVSL+vm66uLvI9
9oy1wGk1kZ3txu/rojcQobmzh+7eILoODouRaCKJ2aBw48Q8yopy2HPkdNoktIFYJBGPDnttSRQp
LfSQ1DRqG1rxOq3YzAZ6AxGa2n3YzAbMZjOh6PD7Tnmxl96+PhoaGlDMTgRBvKAB8oD9NzY2kuO0
YDIomZmBKuNxu/mssZWaz89wztdPIqkx3uukoiSfm0oLyHXZOOfvx2xQcFguFFckY0rzFKNl2Gvb
LQYUWaK1u49oLIHLbsZhMRJLJNL3LigspLNnqBfLddnIc9nYX1ODpmkYzLbBuYCspAqJdXV1iKLI
5EJPRgAi0TjeccVDFnGmowd/f4hwLMGZjh66+0IDDzUAQBSxeotTpuTIRhoGgkFJbVehSJxILM7e
Y83srj9NW3c/AOML8rE4PcQTQzeAeTdOBGDbtm2pexjNlwAYqKQeOHAAgKnjcjICEIjEqJpehXBJ
MTKR1Kg70cq+Y830BMIEwil1t5pSdmj1TsAyAECSVbw3zIdLqszJgdzkfJVI13WSWspjCYLA7fPn
0eEPDLuu285Hp1u3giCgGE2DAUiyjCBKaQBlRZkBiMQS5HpzsOVNuuy4YCSKroPVqCLKCs4JN17i
UXKw5Q2uG4Yig6FdLFabnSVLlnBuGAAWo8r0yQUcPXqMhoYGDFb3oCLpgO8TUC1Z1NfXE4vFKBuf
nREAQUi5VFfpDFSra8RxmqYTSySwWc14yuegWoamtO6pt2CwXzDFUDROLJHEZbcgihdphygy6aY7
sNlsROOJIdeZe+MEFFli69a3UqU22+B7pZ2/arIQi8U4cOAAE/PdOK2mMQOQBBFN1xElhbzpX8Kc
PW7EsYVFE3nqx0+mbX9In0FSyK1ciNlTmFb5Dn8ARRJx2y0ggMHmIq9yIXJW/ojace/s6wB4/fXX
h9j/oL7A+R927NjBrFmzmFaSz0d1Y6vhmQwK4VjqLUgGE7mVC4n2dhLqbiERCQACstGCyZXHt7+7
mvKJeUji9rQtDwFqMJE77U7CvjYi/nZUj5V7l8xiRr/Gq7tOYLC50pleCsDgrlBhtoOq0kKqq6up
q6vDYPMMadakASiqMQ3gRz/6EVWlhWMCIIkiDquRlkticYMjG4NjqEkZFZl4Ijniww8C68rD5Moj
JAjMu3MxuS4bu07/ljZfygPE4kmCkRge+2DvsXzu9QgC/PrXv07tB8OUxdMmIIgiiiWLTz75hFgs
RlVpwRiDICOiIOAPhEc13mYxjrlgouk66z+oRZZE/vbO6YN+6+oN4nFaBlWF75lZRl9/Pxs2bECU
VFSTZWQAAEaLnVAoRE1NDSUFY9sHzIaU/fWHoqMKmLxZ1owKL1v3HKWrN8i9c67DbTcPAmA2KJgH
grgls8pw2c2sf/VVAoEAFlfusA3cQQDO7wPbt29HEARmX188+lxAkdLqeCWpLMlHFASOn+kcM4BY
PMmrfzqAQZH5h8W3XPj/QAAkSSKyJLJq0U3E4wnWrl077O4/LADFYEQQJTZv3gzA7ZUTR70wX39o
IGGxXXHs7ZWTBlpeTRm52z/uPExLVy/3zb2O4tystAbqOkRjCRbPLCPfY+eVV16mqakJsyt/yOY3
LABBEDE6sqmrq6OxsZFZ1xVhHibtHE78/WE6/AHKiryol6nSmg0Ki2ZMwdcfZu+xMxkBiCeS/Grr
XiRR5Fv33IIgwLgcJ129QRKaxt8vqiKZTPLcc8+NuPkNCwDAZHGkaulvvolBkZlVPn7UC/vfg43Y
zQYWVk0ecczdM6diNals3X102Lh9tPLevs/54mwXd1aVctfNU3HZTNQ1trJ87vWMz3Gyfv16Ghoa
MGXlpVPfUQFQjCYQBN58881B6jq6UvVnJDWN1ffeeiHRuUS+etuNJDWNP+48dFUFGE3XeWHLHgQB
Hl2eKufvrj/NQ0tnEQqHeeqpp1KxgfPyid0QAKIoYbRnU11dTWtrK3NvnDDq9Li5o4eX3t1PTpaV
td9ePCQyKy30MCnfTfXRZtoHfPjVyMeHT3G06Rweh4XOniDTJ+fjsBh5+ic/oampCYu74LJvH0Cy
ufOfHBrTC4T7uvF6vdx+2zxauvr4fJQ7dt2JVqaMy2Zm+XiWzi7nZJuPswO9wa8vmEZlST4vvrOP
hpauP0tp/LPGNu6dez0mg8KU8dmcaGxk5cqVJDUNmzufZCJONBwgEugl1O8nEY8iSXK6KDosAElW
CPZ00tR0itWrV+NxWNKtpSuJruvEkxoLp5dgNqh8+eYpLJ97PRUl+dxWMRFZFnlj52EC4SjRePKq
AfgDYWLxBLdeV4QgCKy4/34aGhpS1ee+LsJ9XUQDPcTD/ZhUkYC/k0igB6PFiSjJIx+ROX9Q4oMP
PmDhwoV866cbR9WOriot5OffXUYyEed7jz7KggUL+NKiRTgdjnQmKIoC4WicZ177iG17j2f88IIA
//I3t7N87g3p8sGxY8fYtWsXPT09GI1GvF4vU6dOZcqUKZhMJj7++GPmz5+PbHLiLpgwMoBEPErn
qXoWLFjA9u3b2X3kNN/9+ZbLLqg4N4uXfvhVzKrC8uX3pQoQgCzL3HnnnbzzzjupRuWnR1gwrQSb
2ciDazZw+DJHXy4ni2eW8dSqOznZ5uOPOw5RVVrA/MqJyJJ0SUEmSV8oistmJplMkp2dTV8wQk5x
+cinxGTFgNGRw4cffkh1dTW3zpzJzWXj2DeC73bZTPxs9TLsZiMPP/xw+uEBCgoK0gnJs7/fwcZd
h3l7zzF+8/hX+eGK+fzdM69nBGDB9JSH+qdfvM2Zzh7+uPMQZqPK+BwndouBSDRBbzBCQbadf14x
H2ywbt06/H4/Zlf+8F5gUKUlK5XFPfbYY2iaxg/vvy0d8l4a2//Hw0vI99hZu3YtL7zwAjabjXvu
uYfnn3+eQ4cOUVBQwC+3VrNx12GAdAdnYr4rYxMoLcxGB8529QyqHB1v7uBQYxsWo8oj993Kz1Yv
I89l49lnn+Xxxx9HlA3pA1OXPSeoqEbMrjz27NnDSy+9xDe/+U3+/e8W8sTL73O+wSOKAk8/uIjr
J+SyceNG3n//fXbs2MHs2bOR5dTle/pDrHl9Jxt2XDh08ch9Kd99NRuh3WJEADY+tZLG1m6SSQ2X
3YzHYSHfbU/XD/cfOMDqf/xH9u7diyDJuMeVIl3cF7hs2pqVQ7ink0cffZRp06bx5ZurEAWB5/6w
E1EU+OcV87m9chJ79lTz4x//mIMHDyLLMg1nu6j5/Cw1n5/hwBcthAfq9bIk8t3lc/j6gkp0XR/V
ibGRNkBFEunrD+CxGRh/UcDW09NL/eHD7N79KZs2beKjjz5C0zRUmxunJz/98KMCIEoyroISus8c
Z9myZWzatIlFN9/Mohml6TH7ampYvPhuXC4XoigSjSeobWjl4IlWznb24rKZceWbmDY5n6/Mu4EC
j4PGkycpLioiEolkBCDLZkaRJf60ayfLli3D6/Wiqirnzp0jHA5fUlmy4MouHPaw5KjOCqsmC468
SbS0NDJnzhy+//3vs3jxYjRN46233uIXv/gF0WgUv9/PAw88wH+sW8eKOypYcUfFMOlsnBdffJEf
/OAH+P1+4tFwRgBys1IPc+bMGZLJJK2tremETjbakI1mDEYLitGUrnYNu9mPuuBhcyIrZfjbTrFm
zRrWrFlzQR1FCWd+CUF/J+vXr2fDhg3cddddVFZWUlpaiqIodHV1cfDgQd555x1aW1sRBAFBEEjG
MztGk5OVSrtbWlKxSe7kael211hEHstg1Wgmp6iMSDiQfnOKasRgtqZyCIudcH8PAV87W7ZsYcuW
4eMG2WAlEQ2QSCSQRSEjAN6LNEAQpYwefswAztcOTRY7Joud4XIIsz0Ls91JIh4jGY+TTMTR0REF
EUlRUVQjsUgI39nPUwAkKaOFFww0cZuamhAlNWNPIvMXEQFZMaR7jsN3UCAWi6EomS2hMDsVWp84
cQJRyRyAyF9BzqtrPB7PGECB20YkEqGtrQ1RUq4tAOdPo4RCIUwmUwYAId/j4OTJk2iaNsivXxsa
MADA5/OR5XSMeX62w4rJoHLixIlBTZ1rzgR8Ph+qcqGWP1b7b2xMda6uWQ3o7u5Ox/RjkXEDB6TP
A5Bl5VrTAAHZYKWpKdUXGM2J74vlhgmpA0+1tbVIqvna0wAA1WJj//79AEzOHf3BLFEUmF0+jt7e
XmprazE5PFe1jr8aAIPJRnV1NZqmseimEkb73eU9t0wl2+XgjTfeIBqNYrTYrk0AqsnM6eZm3nrr
LcpLilg4ffIV55QXe/neV24lEonwzDPPYMrKuyoP8FcFIIoSJoeXJ554gmg0yr9+fT7TR2jJe7Ns
PHLvTF58bDlWs4mHHnqIkydPXbHpMar9KKNvh/9MkohF6WyqZ+XKlbz88ssgCFQfaaa+qT11tj/L
yvVF2UwZn4soCrS3t/Od73yHLVu24B43ddh+/zUFACDQ203/uSbmz5/PunXrqKysHPR7Mplk3759
vPbaa/z2t78lGIrizBv5S9BrDgBAsM9HX/uplEeYPJnJkydjMBhoaWnh+PHj9PX1IQgipqxcbFnZ
6a7O/xsAkPpwK9jvJxbsJxHpRxAlJIMFxWjBYLKgmsyX/Qg6U/k/yqkYkbGUgQQAAAAASUVORK5C
YII=
--Apple-Mail-ABAB8549-B265-4E8F-B3F1-FEA37FFA3370--
--Apple-Mail-5B35C4EA-C086-452D-B901-07D1E4C11685--
Attachments:
[image/x-icon] favicon.ico (15.1K, ../../99B2CBBB-D6E2-4704-9E10-B90E054ACE55@gmail.com/2-favicon.ico)
download | view image
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
@ 2025-02-05 12:02 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 18:03 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
0 siblings, 2 replies; 18+ messages in thread
From: Guillermo E. Villanueva @ 2025-02-05 12:02 UTC (permalink / raw)
To: Horacio Miranda <hmiranda@gmail.com>; +Cc: Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
https://explain.depesz.com/s/R3Fh
Si lo ejecuto solo hasta el filtro de companies.id devuelve el resultado en
menos de 1 segundo
Ese campo es PK de la tabla companies, si lo resuelve tan rápido al de las
PK porque priorizar un indice de la misma tabla donde las columnas no son
PK?
El mar, 4 feb 2025 a las 22:34, Horacio Miranda (<hmiranda@gmail.com>)
escribió:
> Usa depez para compartir el plan de ejecución por favor
> New explain | explain.depesz.com <https://explain.depesz.com/;
> explain.depesz.com
> [image: favicon.ico] <https://explain.depesz.com/;
> <https://explain.depesz.com/;
>
>
> Usa esta forma
> explain (analyze,buffers) select ..
>
>
> Regards,
> Horacio Miranda
>
> On 5 Feb 2025, at 11:49 AM, Jairo Graterón <jgrateron@gmail.com> wrote:
>
>
> Saludos
>
> id es de tipo int o bigint?
>
> Prueba con esta otra forma de hacer el IN y nos comentas.
>
>
> "companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
> 1380939753]::integer)
>
> si es tipo bigint
>
> "companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
> 1380939753]::bigint[])
>
>
>
> El mar, 4 feb 2025 a las 12:43, Guillermo E. Villanueva (<
> guillermovil@gmail.com>) escribió:
>
>> Postgresql 13
>> En una query como esta:
>>
>> explain select
>>
>> *
>>
>> from
>>
>> "companies"
>>
>> inner join "subclients" on "subclients"."id" = "companies"."subclient_id"
>>
>> inner join "temas" on "temas"."id" = "companies"."main_tema_id"
>>
>> left join "domains" on "domains"."id" = "companies"."domain_id"
>>
>> left join "papers" on "papers"."id" = "domains"."paper_id"
>>
>> left join "tematicas" on "tematicas"."id" = "domains"."tematica_id"
>>
>> left join "special_values" on "special_values"."subclient_id" =
>> "companies"."subclient_id"
>>
>> where
>>
>> "companies"."id" in (1381059542, 1380939758, 1380939757, 1380939753)
>>
>> and "companies"."subclient_id" in (13579, 13580)
>>
>> and companies.fulldate >= '2025-01-31 09:30' and companies.fulldate < '2025-02-04
>> 09:30'
>>
>> and "companies"."hidden_by_contact" is null
>>
>> and (
>>
>> (subclients.show_3300 is not true and companies.ep_file !~ '_print3300')
>>
>> or subclients.show_3300 is true
>>
>> )
>>
>> and "domains"."p_or_d" in ('p', 'd', 'b')
>>
>> Tengo este plan de ejecución:
>> Nested Loop Left Join (cost=6.70..54.38 rows=1 width=5276)
>> -> Nested Loop Left Join (cost=2.28..45.94 rows=1 width=2707)
>> -> Nested Loop Left Join (cost=2.13..41.74 rows=1 width=2688)
>> -> Nested Loop (cost=1.71..33.80 rows=1 width=2655)
>> -> Nested Loop (cost=1.28..25.36 rows=1 width=1781)
>> -> Nested Loop (cost=0.86..16.92 rows=1
>> width=1673)
>> -> Index Scan using
>> companies_fulldate_subclient_id_idx on companies (cost=0.57..8.60 rows=1
>> width=1113)
>> Index Cond: ((fulldate >=
>> '2025-01-31 09:30:00'::timestamp without time zone) AND (fulldate <
>> '2025-02-04 09:30:00'::timestamp without time zone))
>> Filter: ((hidden_by_contact IS
>> NULL) AND (subclient_id = ANY ('{13579,13580}'::integer[])) AND (id = ANY
>> ('{1381059542,1380939758,1380939757,1380939753}'::integer[])))
>> -> Index Scan using subclients2_pkey on
>> subclients (cost=0.29..8.31 rows=1 width=560)
>> Index Cond: (id =
>> companies.subclient_id)
>> Filter: (((show_3300 IS NOT TRUE)
>> AND ((companies.ep_file)::text !~ '_print3300'::text)) OR (show_3300 IS
>> TRUE))
>> -> Index Scan using temas_pkey on temas
>> (cost=0.42..8.44 rows=1 width=108)
>> Index Cond: (id = companies.main_tema_id)
>> -> Index Scan using domains_pkey on domains
>> (cost=0.42..8.44 rows=1 width=874)
>> Index Cond: (id = companies.domain_id)
>> Filter: ((p_or_d)::text = ANY
>> ('{p,d,b}'::text[]))
>> -> Index Scan using papers_pkey on papers
>> (cost=0.42..7.93 rows=1 width=33)
>> Index Cond: (id = domains.paper_id)
>> -> Index Scan using tematicas_pkey on tematicas
>> (cost=0.14..4.16 rows=1 width=19)
>> Index Cond: (id = domains.tematica_id)
>> -> Bitmap Heap Scan on special_values (cost=4.42..8.43 rows=1
>> width=2569)
>> Recheck Cond: (subclient_id = companies.subclient_id)
>> -> Bitmap Index Scan on special_values_subclient_id_idx
>> (cost=0.00..4.42 rows=1 width=0)
>> Index Cond: (subclient_id = companies.subclient_id)
>>
>> ya hice un ANALYZE.
>> La tabla companies tiene millones de filas.
>> La clave primaria de companies es "id"
>> No entiendo porque postgres no utiliza primero que nada ese índice para
>> reducir las filas de resultado, existe forma de forzar a que lo use? o es
>> correcto que no lo use?
>>
>>
>> Desde ya muchas gracias por los comentarios.
>>
>> Saludos.
>>
>> Guillermo
>>
>
Attachments:
[application/octet-stream] favicon.ico (15.1K, ../../CANm+PCBVe=MipZ3gyyTNmtrLmWMRtMZ=oCymp-dQch-9bTWgKQ@mail.gmail.com/3-favicon.ico)
download
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
@ 2025-02-05 12:11 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
1 sibling, 1 reply; 18+ messages in thread
From: Guillermo E. Villanueva @ 2025-02-05 12:11 UTC (permalink / raw)
To: Horacio Miranda <hmiranda@gmail.com>; +Cc: Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Jaja si engaño a pg y cambio la condición
and companies.fulldate::text >= '2025-01-31 09:30' and companies.fulldate::
text < '2025-02-04 09:30'
ya no usa el índice secundario, usa el índice de la PK y resuelve la query
en menos de un segundo , lo tengo resuelto así pero me quedo con la duda de
porque el planificador lo hace mal de la otra manera (para mi)
El mié, 5 feb 2025 a las 9:02, Guillermo E. Villanueva (<
guillermovil@gmail.com>) escribió:
> https://explain.depesz.com/s/R3Fh
>
> Si lo ejecuto solo hasta el filtro de companies.id devuelve el resultado
> en menos de 1 segundo
> Ese campo es PK de la tabla companies, si lo resuelve tan rápido al de las
> PK porque priorizar un indice de la misma tabla donde las columnas no son
> PK?
>
> El mar, 4 feb 2025 a las 22:34, Horacio Miranda (<hmiranda@gmail.com>)
> escribió:
>
>> Usa depez para compartir el plan de ejecución por favor
>> New explain | explain.depesz.com <https://explain.depesz.com/;
>> explain.depesz.com
>> [image: favicon.ico] <https://explain.depesz.com/;
>> <https://explain.depesz.com/;
>>
>>
>> Usa esta forma
>> explain (analyze,buffers) select ..
>>
>>
>> Regards,
>> Horacio Miranda
>>
>> On 5 Feb 2025, at 11:49 AM, Jairo Graterón <jgrateron@gmail.com> wrote:
>>
>>
>> Saludos
>>
>> id es de tipo int o bigint?
>>
>> Prueba con esta otra forma de hacer el IN y nos comentas.
>>
>>
>> "companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
>> 1380939753]::integer)
>>
>> si es tipo bigint
>>
>> "companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
>> 1380939753]::bigint[])
>>
>>
>>
>> El mar, 4 feb 2025 a las 12:43, Guillermo E. Villanueva (<
>> guillermovil@gmail.com>) escribió:
>>
>>> Postgresql 13
>>> En una query como esta:
>>>
>>> explain select
>>>
>>> *
>>>
>>> from
>>>
>>> "companies"
>>>
>>> inner join "subclients" on "subclients"."id" = "companies".
>>> "subclient_id"
>>>
>>> inner join "temas" on "temas"."id" = "companies"."main_tema_id"
>>>
>>> left join "domains" on "domains"."id" = "companies"."domain_id"
>>>
>>> left join "papers" on "papers"."id" = "domains"."paper_id"
>>>
>>> left join "tematicas" on "tematicas"."id" = "domains"."tematica_id"
>>>
>>> left join "special_values" on "special_values"."subclient_id" =
>>> "companies"."subclient_id"
>>>
>>> where
>>>
>>> "companies"."id" in (1381059542, 1380939758, 1380939757, 1380939753)
>>>
>>> and "companies"."subclient_id" in (13579, 13580)
>>>
>>> and companies.fulldate >= '2025-01-31 09:30' and companies.fulldate < '2025-02-04
>>> 09:30'
>>>
>>> and "companies"."hidden_by_contact" is null
>>>
>>> and (
>>>
>>> (subclients.show_3300 is not true and companies.ep_file !~ '_print3300')
>>>
>>> or subclients.show_3300 is true
>>>
>>> )
>>>
>>> and "domains"."p_or_d" in ('p', 'd', 'b')
>>>
>>> Tengo este plan de ejecución:
>>> Nested Loop Left Join (cost=6.70..54.38 rows=1 width=5276)
>>> -> Nested Loop Left Join (cost=2.28..45.94 rows=1 width=2707)
>>> -> Nested Loop Left Join (cost=2.13..41.74 rows=1 width=2688)
>>> -> Nested Loop (cost=1.71..33.80 rows=1 width=2655)
>>> -> Nested Loop (cost=1.28..25.36 rows=1 width=1781)
>>> -> Nested Loop (cost=0.86..16.92 rows=1
>>> width=1673)
>>> -> Index Scan using
>>> companies_fulldate_subclient_id_idx on companies (cost=0.57..8.60 rows=1
>>> width=1113)
>>> Index Cond: ((fulldate >=
>>> '2025-01-31 09:30:00'::timestamp without time zone) AND (fulldate <
>>> '2025-02-04 09:30:00'::timestamp without time zone))
>>> Filter: ((hidden_by_contact IS
>>> NULL) AND (subclient_id = ANY ('{13579,13580}'::integer[])) AND (id = ANY
>>> ('{1381059542,1380939758,1380939757,1380939753}'::integer[])))
>>> -> Index Scan using subclients2_pkey on
>>> subclients (cost=0.29..8.31 rows=1 width=560)
>>> Index Cond: (id =
>>> companies.subclient_id)
>>> Filter: (((show_3300 IS NOT TRUE)
>>> AND ((companies.ep_file)::text !~ '_print3300'::text)) OR (show_3300 IS
>>> TRUE))
>>> -> Index Scan using temas_pkey on temas
>>> (cost=0.42..8.44 rows=1 width=108)
>>> Index Cond: (id = companies.main_tema_id)
>>> -> Index Scan using domains_pkey on domains
>>> (cost=0.42..8.44 rows=1 width=874)
>>> Index Cond: (id = companies.domain_id)
>>> Filter: ((p_or_d)::text = ANY
>>> ('{p,d,b}'::text[]))
>>> -> Index Scan using papers_pkey on papers
>>> (cost=0.42..7.93 rows=1 width=33)
>>> Index Cond: (id = domains.paper_id)
>>> -> Index Scan using tematicas_pkey on tematicas
>>> (cost=0.14..4.16 rows=1 width=19)
>>> Index Cond: (id = domains.tematica_id)
>>> -> Bitmap Heap Scan on special_values (cost=4.42..8.43 rows=1
>>> width=2569)
>>> Recheck Cond: (subclient_id = companies.subclient_id)
>>> -> Bitmap Index Scan on special_values_subclient_id_idx
>>> (cost=0.00..4.42 rows=1 width=0)
>>> Index Cond: (subclient_id = companies.subclient_id)
>>>
>>> ya hice un ANALYZE.
>>> La tabla companies tiene millones de filas.
>>> La clave primaria de companies es "id"
>>> No entiendo porque postgres no utiliza primero que nada ese índice para
>>> reducir las filas de resultado, existe forma de forzar a que lo use? o es
>>> correcto que no lo use?
>>>
>>>
>>> Desde ya muchas gracias por los comentarios.
>>>
>>> Saludos.
>>>
>>> Guillermo
>>>
>>
Attachments:
[application/octet-stream] favicon.ico (15.1K, ../../CANm+PCD0msujcJTCe4CscC-_zzPgc6x=WEbfs_dqtDXcyKALuQ@mail.gmail.com/3-favicon.ico)
download
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
@ 2025-02-05 12:13 ` Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-05 12:35 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Álvaro Herrera @ 2025-02-05 12:13 UTC (permalink / raw)
To: Guillermo E. Villanueva <guillermovil@gmail.com>; +Cc: Horacio Miranda <hmiranda@gmail.com>; Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Guillermo E. Villanueva escribió:
> Jaja si engaño a pg y cambio la condición
> and companies.fulldate::text >= '2025-01-31 09:30' and companies.fulldate::
> text < '2025-02-04 09:30'
>
> ya no usa el índice secundario, usa el índice de la PK y resuelve la query
> en menos de un segundo , lo tengo resuelto así pero me quedo con la duda de
> porque el planificador lo hace mal de la otra manera (para mi)
Hmm, es raro. ¿Has visto el tamaño de los índices? ¿Qué tienes en
effective_cache_size y shared_buffers?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
@ 2025-02-05 12:35 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 14:13 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 15:49 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 2 replies; 18+ messages in thread
From: Guillermo E. Villanueva @ 2025-02-05 12:35 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Horacio Miranda <hmiranda@gmail.com>; Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Hola Alvaro cómo estas?
Los índices de los que hablo tienen unos 27GB cada uno
La tabla tiene unos 1.4TB
effective_cache_size = 48GB
shared_buffers = 24GB
El mié, 5 feb 2025 a las 9:13, Álvaro Herrera (<alvherre@alvh.no-ip.org>)
escribió:
> Guillermo E. Villanueva escribió:
> > Jaja si engaño a pg y cambio la condición
> > and companies.fulldate::text >= '2025-01-31 09:30' and
> companies.fulldate::
> > text < '2025-02-04 09:30'
> >
> > ya no usa el índice secundario, usa el índice de la PK y resuelve la
> query
> > en menos de un segundo , lo tengo resuelto así pero me quedo con la duda
> de
> > porque el planificador lo hace mal de la otra manera (para mi)
>
> Hmm, es raro. ¿Has visto el tamaño de los índices? ¿Qué tienes en
> effective_cache_size y shared_buffers?
>
> --
> Álvaro Herrera PostgreSQL Developer —
> https://www.EnterpriseDB.com/
>
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-05 12:35 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
@ 2025-02-05 14:13 ` Jairo Graterón <jgrateron@gmail.com>
2025-02-05 14:23 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
1 sibling, 1 reply; 18+ messages in thread
From: Jairo Graterón @ 2025-02-05 14:13 UTC (permalink / raw)
To: Guillermo E. Villanueva <guillermovil@gmail.com>; +Cc: Álvaro Herrera <alvherre@alvh.no-ip.org>; Horacio Miranda <hmiranda@gmail.com>; pgsql-es-ayuda
Buen día
prueba modificando ésta variable (al ejecutar en psql sólo lo modifica la
sesión actual)
set random_page_cost=1.0;
y luego el explain original.
Saludos.
El mié, 5 feb 2025 a las 8:35, Guillermo E. Villanueva (<
guillermovil@gmail.com>) escribió:
> Hola Alvaro cómo estas?
> Los índices de los que hablo tienen unos 27GB cada uno
> La tabla tiene unos 1.4TB
>
> effective_cache_size = 48GB
> shared_buffers = 24GB
>
> El mié, 5 feb 2025 a las 9:13, Álvaro Herrera (<alvherre@alvh.no-ip.org>)
> escribió:
>
>> Guillermo E. Villanueva escribió:
>> > Jaja si engaño a pg y cambio la condición
>> > and companies.fulldate::text >= '2025-01-31 09:30' and
>> companies.fulldate::
>> > text < '2025-02-04 09:30'
>> >
>> > ya no usa el índice secundario, usa el índice de la PK y resuelve la
>> query
>> > en menos de un segundo , lo tengo resuelto así pero me quedo con la
>> duda de
>> > porque el planificador lo hace mal de la otra manera (para mi)
>>
>> Hmm, es raro. ¿Has visto el tamaño de los índices? ¿Qué tienes en
>> effective_cache_size y shared_buffers?
>>
>> --
>> Álvaro Herrera PostgreSQL Developer —
>> https://www.EnterpriseDB.com/
>>
>
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-05 12:35 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 14:13 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
@ 2025-02-05 14:23 ` Guillermo E. Villanueva <guillermovil@gmail.com>
0 siblings, 0 replies; 18+ messages in thread
From: Guillermo E. Villanueva @ 2025-02-05 14:23 UTC (permalink / raw)
To: Jairo Graterón <jgrateron@gmail.com>; +Cc: Álvaro Herrera <alvherre@alvh.no-ip.org>; Horacio Miranda <hmiranda@gmail.com>; pgsql-es-ayuda
Gracias.
Lo sigue planificando mal con ese random_page_cost
El mié, 5 feb 2025 a las 11:13, Jairo Graterón (<jgrateron@gmail.com>)
escribió:
> Buen día
>
> prueba modificando ésta variable (al ejecutar en psql sólo lo modifica la
> sesión actual)
>
> set random_page_cost=1.0;
>
> y luego el explain original.
>
> Saludos.
>
>
> El mié, 5 feb 2025 a las 8:35, Guillermo E. Villanueva (<
> guillermovil@gmail.com>) escribió:
>
>> Hola Alvaro cómo estas?
>> Los índices de los que hablo tienen unos 27GB cada uno
>> La tabla tiene unos 1.4TB
>>
>> effective_cache_size = 48GB
>> shared_buffers = 24GB
>>
>> El mié, 5 feb 2025 a las 9:13, Álvaro Herrera (<alvherre@alvh.no-ip.org>)
>> escribió:
>>
>>> Guillermo E. Villanueva escribió:
>>> > Jaja si engaño a pg y cambio la condición
>>> > and companies.fulldate::text >= '2025-01-31 09:30' and
>>> companies.fulldate::
>>> > text < '2025-02-04 09:30'
>>> >
>>> > ya no usa el índice secundario, usa el índice de la PK y resuelve la
>>> query
>>> > en menos de un segundo , lo tengo resuelto así pero me quedo con la
>>> duda de
>>> > porque el planificador lo hace mal de la otra manera (para mi)
>>>
>>> Hmm, es raro. ¿Has visto el tamaño de los índices? ¿Qué tienes en
>>> effective_cache_size y shared_buffers?
>>>
>>> --
>>> Álvaro Herrera PostgreSQL Developer —
>>> https://www.EnterpriseDB.com/
>>>
>>
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-05 12:35 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
@ 2025-02-05 15:49 ` Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-06 11:33 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
1 sibling, 1 reply; 18+ messages in thread
From: Álvaro Herrera @ 2025-02-05 15:49 UTC (permalink / raw)
To: Guillermo E. Villanueva <guillermovil@gmail.com>; +Cc: Horacio Miranda <hmiranda@gmail.com>; Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Guillermo E. Villanueva escribió:
> Hola Alvaro cómo estas?
> Los índices de los que hablo tienen unos 27GB cada uno
> La tabla tiene unos 1.4TB
>
> effective_cache_size = 48GB
> shared_buffers = 24GB
¿y qué dice esto?
select attname, cardinality(histogram_bounds), cardinality(most_common_freqs)
from pg_stats
where tablename = 'companies';
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-05 12:35 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 15:49 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
@ 2025-02-06 11:33 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-06 11:56 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 18+ messages in thread
From: Guillermo E. Villanueva @ 2025-02-06 11:33 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Horacio Miranda <hmiranda@gmail.com>; Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Alvaro te copio el resultado acá:
id 101
subclient_id 101 100
hidden_by_contact 101 6
fulldate 101
title 101 33
pointers 101 100
page_num 101 100
eurl 11
url 101 1
ep_file 101
epoch_time 101 36
add_type 10 15
alt_title 101 10
views 12 6
box 8 23
vp 101 100
clip_ratio 101 2
clip_area 101
tirada 101 75
difusion 101 99
audiencia 101 100
file_type 3
score 101 33
meta_description 101 1
tono 3
saved 2
sortnum 39
domain_id 101 100
approved 1
manual_domains_id
duplicated 2
created_pdf_type 4 7
pdf_created_by 22 52
vo 5
url_views 6 5
print_section_id
advertisement 2
pdf_verified
num_pages 21 12
available 1
evp 101 100
com_value 101 100
companies_group_id 101
is_ungrouped 2
sentiment_score 11
p_vistas 101 100
main_tema_id 101 100
secondary_tema_ids 101 1
enable_eng_tracking 1
engagement_count 5 1
eng_last_tracked 69
usid 101 100
unique_article_id 101
emailed_at
emailed_by_instance_id
last_change_date 101 1
tracked_companies_id 101
paid_article_grab 2
paid_article_conv 2
processing_fulldate 101 1
pdf_downloads
custom_fields_values
El mié, 5 feb 2025 a las 12:49, Álvaro Herrera (<alvherre@alvh.no-ip.org>)
escribió:
> Guillermo E. Villanueva escribió:
> > Hola Alvaro cómo estas?
> > Los índices de los que hablo tienen unos 27GB cada uno
> > La tabla tiene unos 1.4TB
> >
> > effective_cache_size = 48GB
> > shared_buffers = 24GB
>
> ¿y qué dice esto?
>
> select attname, cardinality(histogram_bounds),
> cardinality(most_common_freqs)
> from pg_stats
> where tablename = 'companies';
>
> --
> Álvaro Herrera PostgreSQL Developer —
> https://www.EnterpriseDB.com/
>
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-05 12:35 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 15:49 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-06 11:33 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
@ 2025-02-06 11:56 ` Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-06 12:57 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Álvaro Herrera @ 2025-02-06 11:56 UTC (permalink / raw)
To: Guillermo E. Villanueva <guillermovil@gmail.com>; +Cc: Horacio Miranda <hmiranda@gmail.com>; Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Guillermo E. Villanueva escribió:
> Alvaro te copio el resultado acá:
> id 101
> subclient_id 101 100
> hidden_by_contact 101 6
> fulldate 101
OK, quizás te sirva tomar más estadísticas para id y fulldate.
ALTER TABLE companies ALTER id SET STATISTICS 10000;
ALTER TABLE companies ALTER fulldate SET STATISTICS 10000;
ANALYZE companies;
Con eso, los datos estadísticos sobre esas dos columnas podrían ser más
precisos y potencialmente corregir el problema. OJO: el valor 10000
puede ser excesivamente alto y causar que la optimización de consultas
tome más tiempo. Mídelo y experimenta bajando ese número desde 10000 a
algo entre eso y 100 (el que tienes ahora). Opcionalmente, considerar
las otras columnas que tu consulta tiene en el WHERE.
Si eso no resulta, podrías probar con
CREATE STATISTICS ON id, fulldate FROM companies;
ANALYZE;
Eso captura estadísticas cruzadas entre esas dos columnas, lo cual
podría informar mejor al optimizador respecto del uso de ambas en el
WHERE. Al igual que lo de arriba, puede servir opcionalmente agregar
las otras columnas que tienes en el WHERE.
Si nada de lo anterior resulta, la siguiente opción es forzar el uso del
indexscan metiendo el scan de esa tabla en un subselect. Cuando nos
cuentes del resultado de arriba puedo explicar cómo se hace esto.
Saludos
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Sallah, I said NO camels! That's FIVE camels; can't you count?"
(Indiana Jones)
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-05 12:35 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 15:49 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-06 11:33 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-06 11:56 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
@ 2025-02-06 12:57 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-06 14:12 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 18+ messages in thread
From: Guillermo E. Villanueva @ 2025-02-06 12:57 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Horacio Miranda <hmiranda@gmail.com>; Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Muchas gracias Alvaro, tremendo crack ud.
Luego de ejecutar (en un ambiente de testing)
ALTER TABLE companies ALTER id SET STATISTICS 10000;
ALTER TABLE companies ALTER fulldate SET STATISTICS 10000;
ANALYZE companies;
El explain de la query en cuestión cambió totalmente
Ahora si utiliza primero el índice de la clave primaria y luego recien
filtra por fechas
Si me puedes remitir a algun material para leer al respecto y entender
porque pasaba esto y por que se solucionó te lo agradeceré!
Aunque no necesité la otra solución que comentabas, si me gustaría saberla,
intenté algunas cosas con subqueries pero no mejoraba, lo único que mejoró
fue el casteo
and companies.fulldate*::text* >= '2025-01-31 09:30' and companies.fulldate
*::text* < '2025-02-04 09:30'
De esa manera (parche) evitaba que use el otro índice y se iba por el de la
PK
Muchas gracias de nuevo
El jue, 6 feb 2025 a las 8:56, Álvaro Herrera (<alvherre@alvh.no-ip.org>)
escribió:
> Guillermo E. Villanueva escribió:
> > Alvaro te copio el resultado acá:
> > id 101
> > subclient_id 101 100
> > hidden_by_contact 101 6
> > fulldate 101
>
> OK, quizás te sirva tomar más estadísticas para id y fulldate.
> ALTER TABLE companies ALTER id SET STATISTICS 10000;
> ALTER TABLE companies ALTER fulldate SET STATISTICS 10000;
> ANALYZE companies;
>
> Con eso, los datos estadísticos sobre esas dos columnas podrían ser más
> precisos y potencialmente corregir el problema. OJO: el valor 10000
> puede ser excesivamente alto y causar que la optimización de consultas
> tome más tiempo. Mídelo y experimenta bajando ese número desde 10000 a
> algo entre eso y 100 (el que tienes ahora). Opcionalmente, considerar
> las otras columnas que tu consulta tiene en el WHERE.
>
>
> Si eso no resulta, podrías probar con
> CREATE STATISTICS ON id, fulldate FROM companies;
> ANALYZE;
>
> Eso captura estadísticas cruzadas entre esas dos columnas, lo cual
> podría informar mejor al optimizador respecto del uso de ambas en el
> WHERE. Al igual que lo de arriba, puede servir opcionalmente agregar
> las otras columnas que tienes en el WHERE.
>
>
> Si nada de lo anterior resulta, la siguiente opción es forzar el uso del
> indexscan metiendo el scan de esa tabla en un subselect. Cuando nos
> cuentes del resultado de arriba puedo explicar cómo se hace esto.
>
> Saludos
>
> --
> Álvaro Herrera 48°01'N 7°57'E —
> https://www.EnterpriseDB.com/
> "Sallah, I said NO camels! That's FIVE camels; can't you count?"
> (Indiana Jones)
>
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-05 12:35 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 15:49 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-06 11:33 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-06 11:56 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-06 12:57 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
@ 2025-02-06 14:12 ` Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-07 13:28 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Álvaro Herrera @ 2025-02-06 14:12 UTC (permalink / raw)
To: Guillermo E. Villanueva <guillermovil@gmail.com>; +Cc: Horacio Miranda <hmiranda@gmail.com>; Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Guillermo E. Villanueva escribió:
> Muchas gracias Alvaro, tremendo crack ud.
> Luego de ejecutar (en un ambiente de testing)
>
> ALTER TABLE companies ALTER id SET STATISTICS 10000;
>
> ALTER TABLE companies ALTER fulldate SET STATISTICS 10000;
>
> ANALYZE companies;
> El explain de la query en cuestión cambió totalmente
> Ahora si utiliza primero el índice de la clave primaria y luego recien
> filtra por fechas
>
> Si me puedes remitir a algun material para leer al respecto y entender
> porque pasaba esto y por que se solucionó te lo agradeceré!
Esta charla de Divya Sharma explica lo de las estadísticas,
https://www.postgresql.eu/events/pgconfde2024/schedule/session/5369-understanding-postgresql-statist...
lamentablemente me parece que no hay grabación de la misma.
Vuelvo a insistir que el número 10000 probablemente es mucho más alto de
lo que realmente necesitas, y causa que el optimizador demore más de lo
necesario. Recomendaría probar con otros valores (200, 500) hasta
encontrar un punto intermedio razonable.
> Aunque no necesité la otra solución que comentabas, si me gustaría
> saberla,
La charla de Divya Sharma explica esto también, aunque debe haber alguna
de Tomas Vondra ... ah sí, esta:
https://www.youtube.com/watch?v=xPorz6N8ogE
No conozco recursos en castellano.
> intenté algunas cosas con subqueries pero no mejoraba,
Normalmente el optimizador "aplana" (flatten) las subconsultas, que
esencialmente significa que las elimina y lo vuelve a la misma
estructura que si no tuvieras la subconsulta, por eso no ves ninguna
mejora. Pero si a la subconsulta le agregas OFFSET 0, entonces se
convierte en una "barrera de optimización", evitando que haga ese
aplanamiento, y entonces sí podrías ver que el plan cambia.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Syntax error: function hell() needs an argument.
Please choose what hell you want to involve.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-05 12:35 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 15:49 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-06 11:33 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-06 11:56 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-06 12:57 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-06 14:12 ` Re: plan de ejecución Álvaro Herrera <alvherre@alvh.no-ip.org>
@ 2025-02-07 13:28 ` Guillermo E. Villanueva <guillermovil@gmail.com>
0 siblings, 0 replies; 18+ messages in thread
From: Guillermo E. Villanueva @ 2025-02-07 13:28 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Horacio Miranda <hmiranda@gmail.com>; Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Muchas gracias por todo!!
El jue, 6 feb 2025 a las 11:12, Álvaro Herrera (<alvherre@alvh.no-ip.org>)
escribió:
> Guillermo E. Villanueva escribió:
> > Muchas gracias Alvaro, tremendo crack ud.
> > Luego de ejecutar (en un ambiente de testing)
> >
> > ALTER TABLE companies ALTER id SET STATISTICS 10000;
> >
> > ALTER TABLE companies ALTER fulldate SET STATISTICS 10000;
> >
> > ANALYZE companies;
> > El explain de la query en cuestión cambió totalmente
> > Ahora si utiliza primero el índice de la clave primaria y luego recien
> > filtra por fechas
> >
> > Si me puedes remitir a algun material para leer al respecto y entender
> > porque pasaba esto y por que se solucionó te lo agradeceré!
>
> Esta charla de Divya Sharma explica lo de las estadísticas,
>
> https://www.postgresql.eu/events/pgconfde2024/schedule/session/5369-understanding-postgresql-statist...
> lamentablemente me parece que no hay grabación de la misma.
>
> Vuelvo a insistir que el número 10000 probablemente es mucho más alto de
> lo que realmente necesitas, y causa que el optimizador demore más de lo
> necesario. Recomendaría probar con otros valores (200, 500) hasta
> encontrar un punto intermedio razonable.
>
> > Aunque no necesité la otra solución que comentabas, si me gustaría
> > saberla,
>
> La charla de Divya Sharma explica esto también, aunque debe haber alguna
> de Tomas Vondra ... ah sí, esta:
> https://www.youtube.com/watch?v=xPorz6N8ogE
>
> No conozco recursos en castellano.
>
> > intenté algunas cosas con subqueries pero no mejoraba,
>
> Normalmente el optimizador "aplana" (flatten) las subconsultas, que
> esencialmente significa que las elimina y lo vuelve a la misma
> estructura que si no tuvieras la subconsulta, por eso no ves ninguna
> mejora. Pero si a la subconsulta le agregas OFFSET 0, entonces se
> convierte en una "barrera de optimización", evitando que haga ese
> aplanamiento, y entonces sí podrías ver que el plan cambia.
>
> --
> Álvaro Herrera Breisgau, Deutschland —
> https://www.EnterpriseDB.com/
> Syntax error: function hell() needs an argument.
> Please choose what hell you want to involve.
>
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
@ 2025-02-05 18:03 ` Horacio Miranda <hmiranda@gmail.com>
2025-02-06 12:26 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
1 sibling, 1 reply; 18+ messages in thread
From: Horacio Miranda @ 2025-02-05 18:03 UTC (permalink / raw)
To: Guillermo E. Villanueva <guillermovil@gmail.com>; +Cc: Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Hola, esta parte revisa si lo puedes trabajar, los filtros son después de una lectura de disco o indices para reducir la lectura puedes crear un indice con los filtros.
Index Cond: ((fulldate >= '2025-01-31 09:30:00'::timestamp without time zone) AND (fulldate < '2025-02-04 09:30:00'::timestamp without time zone))
Filter: ((hidden_by_contact IS NULL) AND (subclient_id = ANY ('{13579,13580}'::integer[])) AND (id = ANY ('{1381059542,1380939758,1380939757,1380939753}'::integer[])))
Rows Removed by Filter: 2,022,941
Del plan la columna Rows X el planificador cree que va a devolver 4 lineas usando el indice y la columna rows son las lineas que pasaron realmente por esta condición.
Si puedes hacer una copia de la base en otro ambiente y correr las estadisticas para saber si esto mejora es una opción para no tocar produccion.
Ajustar la consulta para hacer explicito la fecha ( fulldate es tipo timestamp ? en tu tabla ? ) en lo personal tengo la costumbre de hacer las consultas de fecha con esto : to_timestamp o to_date dependiendo del tipo de datos definido en la tabla.
Podrías probar creando en un indice que incluya los campos de los filtros + la fecha algo como esto ( debes usar un nombre adecuado a tu standard ).
create index on companies (fulldate, hidden_by_contact, subclient_id, id) ;
create index on companies (fulldate, subclient_id, id) where hidden_by_contact is null ;
segun el tipo de consultas podrias evaluar particionar la tabla companies.
Prueba en la session cambiando los parámetros ( estos son se HDD no SSD ) eh encontrado que con maquinas virtuales esto anda mejor, pero prueba, un grupo de consultas para saber si es mejor o peor, toma un grupo de 10 consultas significativas.
random_page_cost = 4
effective_io_concurrency = 2
Avisame como te va
NOTA: El depez puedes apretar “add optimization” y agregar cosas que vas cambiando y veras como van cambiando los planes.
> On 6 Feb 2025, at 1:02 AM, Guillermo E. Villanueva <guillermovil@gmail.com> wrote:
>
> https://explain.depesz.com/s/R3Fh
>
> Si lo ejecuto solo hasta el filtro de companies.id <http://companies.id/; devuelve el resultado en menos de 1 segundo
> Ese campo es PK de la tabla companies, si lo resuelve tan rápido al de las PK porque priorizar un indice de la misma tabla donde las columnas no son PK?
>
> El mar, 4 feb 2025 a las 22:34, Horacio Miranda (<hmiranda@gmail.com <mailto:hmiranda@gmail.com>>) escribió:
>> Usa depez para compartir el plan de ejecución por favor
>> New explain | explain.depesz.com
>> explain.depesz.com
>> <favicon.ico>
>> <https://explain.depesz.com/>New explain | explain.depesz.com <https://explain.depesz.com/;
>> explain.depesz.com <https://explain.depesz.com/; <favicon.ico> <https://explain.depesz.com/;
>>
>> Usa esta forma
>> explain (analyze,buffers) select ..
>>
>>
>> Regards,
>> Horacio Miranda
>>
>>> On 5 Feb 2025, at 11:49 AM, Jairo Graterón <jgrateron@gmail.com <mailto:jgrateron@gmail.com>> wrote:
>>>
>>>
>>> Saludos
>>>
>>> id es de tipo int o bigint?
>>>
>>> Prueba con esta otra forma de hacer el IN y nos comentas.
>>>
>>>
>>> "companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757, 1380939753]::integer)
>>>
>>> si es tipo bigint
>>>
>>> "companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757, 1380939753]::bigint[])
>>>
>>>
>>>
>>> El mar, 4 feb 2025 a las 12:43, Guillermo E. Villanueva (<guillermovil@gmail.com <mailto:guillermovil@gmail.com>>) escribió:
>>>> Postgresql 13
>>>> En una query como esta:
>>>> explain select
>>>> *
>>>> from
>>>> "companies"
>>>> inner join "subclients" on "subclients"."id" = "companies"."subclient_id"
>>>> inner join "temas" on "temas"."id" = "companies"."main_tema_id"
>>>> left join "domains" on "domains"."id" = "companies"."domain_id"
>>>> left join "papers" on "papers"."id" = "domains"."paper_id"
>>>> left join "tematicas" on "tematicas"."id" = "domains"."tematica_id"
>>>> left join "special_values" on "special_values"."subclient_id" = "companies"."subclient_id"
>>>> where
>>>> "companies"."id" in (1381059542, 1380939758, 1380939757, 1380939753)
>>>> and "companies"."subclient_id" in (13579, 13580)
>>>> and companies.fulldate >= '2025-01-31 09:30' and companies.fulldate < '2025-02-04 09:30'
>>>> and "companies"."hidden_by_contact" is null
>>>> and (
>>>> (subclients.show_3300 is not true and companies.ep_file !~ '_print3300')
>>>> or subclients.show_3300 is true
>>>> )
>>>> and "domains"."p_or_d" in ('p', 'd', 'b')
>>>>
>>>> Tengo este plan de ejecución:
>>>> Nested Loop Left Join (cost=6.70..54.38 rows=1 width=5276)
>>>> -> Nested Loop Left Join (cost=2.28..45.94 rows=1 width=2707)
>>>> -> Nested Loop Left Join (cost=2.13..41.74 rows=1 width=2688)
>>>> -> Nested Loop (cost=1.71..33.80 rows=1 width=2655)
>>>> -> Nested Loop (cost=1.28..25.36 rows=1 width=1781)
>>>> -> Nested Loop (cost=0.86..16.92 rows=1 width=1673)
>>>> -> Index Scan using companies_fulldate_subclient_id_idx on companies (cost=0.57..8.60 rows=1 width=1113)
>>>> Index Cond: ((fulldate >= '2025-01-31 09:30:00'::timestamp without time zone) AND (fulldate < '2025-02-04 09:30:00'::timestamp without time zone))
>>>> Filter: ((hidden_by_contact IS NULL) AND (subclient_id = ANY ('{13579,13580}'::integer[])) AND (id = ANY ('{1381059542,1380939758,1380939757,1380939753}'::integer[])))
>>>> -> Index Scan using subclients2_pkey on subclients (cost=0.29..8.31 rows=1 width=560)
>>>> Index Cond: (id = companies.subclient_id)
>>>> Filter: (((show_3300 IS NOT TRUE) AND ((companies.ep_file)::text !~ '_print3300'::text)) OR (show_3300 IS TRUE))
>>>> -> Index Scan using temas_pkey on temas (cost=0.42..8.44 rows=1 width=108)
>>>> Index Cond: (id = companies.main_tema_id)
>>>> -> Index Scan using domains_pkey on domains (cost=0.42..8.44 rows=1 width=874)
>>>> Index Cond: (id = companies.domain_id)
>>>> Filter: ((p_or_d)::text = ANY ('{p,d,b}'::text[]))
>>>> -> Index Scan using papers_pkey on papers (cost=0.42..7.93 rows=1 width=33)
>>>> Index Cond: (id = domains.paper_id)
>>>> -> Index Scan using tematicas_pkey on tematicas (cost=0.14..4.16 rows=1 width=19)
>>>> Index Cond: (id = domains.tematica_id)
>>>> -> Bitmap Heap Scan on special_values (cost=4.42..8.43 rows=1 width=2569)
>>>> Recheck Cond: (subclient_id = companies.subclient_id)
>>>> -> Bitmap Index Scan on special_values_subclient_id_idx (cost=0.00..4.42 rows=1 width=0)
>>>> Index Cond: (subclient_id = companies.subclient_id)
>>>>
>>>> ya hice un ANALYZE.
>>>> La tabla companies tiene millones de filas.
>>>> La clave primaria de companies es "id"
>>>> No entiendo porque postgres no utiliza primero que nada ese índice para reducir las filas de resultado, existe forma de forzar a que lo use? o es correcto que no lo use?
>>>>
>>>>
>>>> Desde ya muchas gracias por los comentarios.
>>>>
>>>> Saludos.
>>>>
>>>> Guillermo
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Re: plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 18:03 ` Re: plan de ejecución Horacio Miranda <hmiranda@gmail.com>
@ 2025-02-06 12:26 ` Guillermo E. Villanueva <guillermovil@gmail.com>
0 siblings, 0 replies; 18+ messages in thread
From: Guillermo E. Villanueva @ 2025-02-06 12:26 UTC (permalink / raw)
To: Horacio Miranda <hmiranda@gmail.com>; +Cc: Jairo Graterón <jgrateron@gmail.com>; pgsql-es-ayuda
Hola Horacio gracias por tu rta.
1)
Ejecuté los set para
random_page_cost = 4
effective_io_concurrency = 2
No hubo mejora. El plan sigue siendo el mismo
2)
Ejecuté analyze para todas las tablas
No hubo mejora. El plan sigue siendo el mismo
3)
No hice la conversión to_timestamp por que lo está tomando como tal, sino
no usaría el índice
4) Creé los índices que me sugieres
No hubo mejora. El plan sigue siendo el mismo
Creé los índices que me sugieres, pero de todas maneras, a mi modo de ver
no es lógico que no utilice primero un índice basado en la PK
El mié, 5 feb 2025 a las 15:03, Horacio Miranda (<hmiranda@gmail.com>)
escribió:
> Hola, esta parte revisa si lo puedes trabajar, los filtros son después de
> una lectura de disco o indices para reducir la lectura puedes crear un
> indice con los filtros.
>
>
> - Index Cond: ((fulldate >= '2025-01-31 09:30:00'::timestamp without
> time zone) AND (fulldate < '2025-02-04 09:30:00'::timestamp without time
> zone))
> - Filter: ((hidden_by_contact IS NULL) AND (subclient_id = ANY
> ('{13579,13580}'::integer[])) AND (id = ANY
> ('{1381059542,1380939758,1380939757,1380939753}'::integer[])))
> - Rows Removed by Filter: 2,022,941
>
>
> Del plan la columna Rows X el planificador cree que va a devolver 4 lineas
> usando el indice y la columna rows son las lineas que pasaron realmente por
> esta condición.
>
> Si puedes hacer una copia de la base en otro ambiente y correr las
> estadisticas para saber si esto mejora es una opción para no tocar
> produccion.
> Ajustar la consulta para hacer explicito la fecha ( fulldate es tipo
> timestamp ? en tu tabla ? ) en lo personal tengo la costumbre de hacer las
> consultas de fecha con esto : to_timestamp o to_date dependiendo del tipo
> de datos definido en la tabla.
>
> Podrías probar creando en un indice que incluya los campos de los filtros
> + la fecha algo como esto ( debes usar un nombre adecuado a tu standard ).
> create index on companies (fulldate, hidden_by_contact, subclient_id, id)
> ;
> create index on companies (fulldate, subclient_id, id) where hidden_by_contact
> is null ;
>
> segun el tipo de consultas podrias evaluar particionar la tabla companies.
>
> Prueba en la session cambiando los parámetros ( estos son se HDD no SSD )
> eh encontrado que con maquinas virtuales esto anda mejor, pero prueba, un
> grupo de consultas para saber si es mejor o peor, toma un grupo de 10
> consultas significativas.
>
> random_page_cost = 4
> effective_io_concurrency = 2
>
> Avisame como te va
>
> NOTA: El depez puedes apretar “add optimization” y agregar cosas que vas
> cambiando y veras como van cambiando los planes.
>
>
>
> On 6 Feb 2025, at 1:02 AM, Guillermo E. Villanueva <guillermovil@gmail.com>
> wrote:
>
> https://explain.depesz.com/s/R3Fh
>
> Si lo ejecuto solo hasta el filtro de companies.id devuelve el resultado
> en menos de 1 segundo
> Ese campo es PK de la tabla companies, si lo resuelve tan rápido al de las
> PK porque priorizar un indice de la misma tabla donde las columnas no son
> PK?
>
> El mar, 4 feb 2025 a las 22:34, Horacio Miranda (<hmiranda@gmail.com>)
> escribió:
>
>> Usa depez para compartir el plan de ejecución por favor
>> New explain | explain.depesz.com <https://explain.depesz.com/;
>> explain.depesz.com
>> <favicon.ico> <https://explain.depesz.com/; <https://explain.depesz.com/;
>>
>>
>> Usa esta forma
>> explain (analyze,buffers) select ..
>>
>>
>> Regards,
>> Horacio Miranda
>>
>> On 5 Feb 2025, at 11:49 AM, Jairo Graterón <jgrateron@gmail.com> wrote:
>>
>>
>> Saludos
>>
>> id es de tipo int o bigint?
>>
>> Prueba con esta otra forma de hacer el IN y nos comentas.
>>
>>
>> "companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
>> 1380939753]::integer)
>>
>> si es tipo bigint
>>
>> "companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
>> 1380939753]::bigint[])
>>
>>
>>
>> El mar, 4 feb 2025 a las 12:43, Guillermo E. Villanueva (<
>> guillermovil@gmail.com>) escribió:
>>
>>> Postgresql 13
>>> En una query como esta:
>>> explain select
>>> *
>>> from
>>> "companies"
>>> inner join "subclients" on "subclients"."id" = "companies".
>>> "subclient_id"
>>> inner join "temas" on "temas"."id" = "companies"."main_tema_id"
>>> left join "domains" on "domains"."id" = "companies"."domain_id"
>>> left join "papers" on "papers"."id" = "domains"."paper_id"
>>> left join "tematicas" on "tematicas"."id" = "domains"."tematica_id"
>>> left join "special_values" on "special_values"."subclient_id" =
>>> "companies"."subclient_id"
>>> where
>>> "companies"."id" in (1381059542, 1380939758, 1380939757, 1380939753)
>>> and "companies"."subclient_id" in (13579, 13580)
>>> and companies.fulldate >= '2025-01-31 09:30' and companies.fulldate < '2025-02-04
>>> 09:30'
>>> and "companies"."hidden_by_contact" is null
>>> and (
>>> (subclients.show_3300 is not true and companies.ep_file !~ '_print3300')
>>> or subclients.show_3300 is true
>>> )
>>> and "domains"."p_or_d" in ('p', 'd', 'b')
>>>
>>> Tengo este plan de ejecución:
>>> Nested Loop Left Join (cost=6.70..54.38 rows=1 width=5276)
>>> -> Nested Loop Left Join (cost=2.28..45.94 rows=1 width=2707)
>>> -> Nested Loop Left Join (cost=2.13..41.74 rows=1 width=2688)
>>> -> Nested Loop (cost=1.71..33.80 rows=1 width=2655)
>>> -> Nested Loop (cost=1.28..25.36 rows=1 width=1781)
>>> -> Nested Loop (cost=0.86..16.92 rows=1
>>> width=1673)
>>> -> Index Scan using
>>> companies_fulldate_subclient_id_idx on companies (cost=0.57..8.60 rows=1
>>> width=1113)
>>> Index Cond: ((fulldate >=
>>> '2025-01-31 09:30:00'::timestamp without time zone) AND (fulldate <
>>> '2025-02-04 09:30:00'::timestamp without time zone))
>>> Filter: ((hidden_by_contact IS
>>> NULL) AND (subclient_id = ANY ('{13579,13580}'::integer[])) AND (id = ANY
>>> ('{1381059542,1380939758,1380939757,1380939753}'::integer[])))
>>> -> Index Scan using subclients2_pkey on
>>> subclients (cost=0.29..8.31 rows=1 width=560)
>>> Index Cond: (id =
>>> companies.subclient_id)
>>> Filter: (((show_3300 IS NOT TRUE)
>>> AND ((companies.ep_file)::text !~ '_print3300'::text)) OR (show_3300 IS
>>> TRUE))
>>> -> Index Scan using temas_pkey on temas
>>> (cost=0.42..8.44 rows=1 width=108)
>>> Index Cond: (id = companies.main_tema_id)
>>> -> Index Scan using domains_pkey on domains
>>> (cost=0.42..8.44 rows=1 width=874)
>>> Index Cond: (id = companies.domain_id)
>>> Filter: ((p_or_d)::text = ANY
>>> ('{p,d,b}'::text[]))
>>> -> Index Scan using papers_pkey on papers
>>> (cost=0.42..7.93 rows=1 width=33)
>>> Index Cond: (id = domains.paper_id)
>>> -> Index Scan using tematicas_pkey on tematicas
>>> (cost=0.14..4.16 rows=1 width=19)
>>> Index Cond: (id = domains.tematica_id)
>>> -> Bitmap Heap Scan on special_values (cost=4.42..8.43 rows=1
>>> width=2569)
>>> Recheck Cond: (subclient_id = companies.subclient_id)
>>> -> Bitmap Index Scan on special_values_subclient_id_idx
>>> (cost=0.00..4.42 rows=1 width=0)
>>> Index Cond: (subclient_id = companies.subclient_id)
>>>
>>> ya hice un ANALYZE.
>>> La tabla companies tiene millones de filas.
>>> La clave primaria de companies es "id"
>>> No entiendo porque postgres no utiliza primero que nada ese índice para
>>> reducir las filas de resultado, existe forma de forzar a que lo use? o es
>>> correcto que no lo use?
>>>
>>>
>>> Desde ya muchas gracias por los comentarios.
>>>
>>> Saludos.
>>>
>>> Guillermo
>>>
>>
>
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: plan de ejecución
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Re: plan de ejecución Jairo Graterón <jgrateron@gmail.com>
@ 2025-02-05 12:00 ` Guillermo E. Villanueva <guillermovil@gmail.com>
1 sibling, 0 replies; 18+ messages in thread
From: Guillermo E. Villanueva @ 2025-02-05 12:00 UTC (permalink / raw)
To: Jairo Graterón <jgrateron@gmail.com>; +Cc: pgsql-es-ayuda
Es de tipo integer
probé con "companies"."id" = ANY (ARRAY[1381059542::integer, 1380939758::
integer, 1380939757::integer, 1380939753::integer])
pero lo sigue poniendo como filtro dentro de la búsqueda de otro indice que
no es PK
El mar, 4 feb 2025 a las 19:49, Jairo Graterón (<jgrateron@gmail.com>)
escribió:
> Saludos
>
> id es de tipo int o bigint?
>
> Prueba con esta otra forma de hacer el IN y nos comentas.
>
>
> "companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
> 1380939753]::integer)
>
> si es tipo bigint
>
> "companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
> 1380939753]::bigint[])
>
>
>
> El mar, 4 feb 2025 a las 12:43, Guillermo E. Villanueva (<
> guillermovil@gmail.com>) escribió:
>
>> Postgresql 13
>> En una query como esta:
>>
>> explain select
>>
>> *
>>
>> from
>>
>> "companies"
>>
>> inner join "subclients" on "subclients"."id" = "companies"."subclient_id"
>>
>> inner join "temas" on "temas"."id" = "companies"."main_tema_id"
>>
>> left join "domains" on "domains"."id" = "companies"."domain_id"
>>
>> left join "papers" on "papers"."id" = "domains"."paper_id"
>>
>> left join "tematicas" on "tematicas"."id" = "domains"."tematica_id"
>>
>> left join "special_values" on "special_values"."subclient_id" =
>> "companies"."subclient_id"
>>
>> where
>>
>> "companies"."id" in (1381059542, 1380939758, 1380939757, 1380939753)
>>
>> and "companies"."subclient_id" in (13579, 13580)
>>
>> and companies.fulldate >= '2025-01-31 09:30' and companies.fulldate < '2025-02-04
>> 09:30'
>>
>> and "companies"."hidden_by_contact" is null
>>
>> and (
>>
>> (subclients.show_3300 is not true and companies.ep_file !~ '_print3300')
>>
>> or subclients.show_3300 is true
>>
>> )
>>
>> and "domains"."p_or_d" in ('p', 'd', 'b')
>>
>> Tengo este plan de ejecución:
>> Nested Loop Left Join (cost=6.70..54.38 rows=1 width=5276)
>> -> Nested Loop Left Join (cost=2.28..45.94 rows=1 width=2707)
>> -> Nested Loop Left Join (cost=2.13..41.74 rows=1 width=2688)
>> -> Nested Loop (cost=1.71..33.80 rows=1 width=2655)
>> -> Nested Loop (cost=1.28..25.36 rows=1 width=1781)
>> -> Nested Loop (cost=0.86..16.92 rows=1
>> width=1673)
>> -> Index Scan using
>> companies_fulldate_subclient_id_idx on companies (cost=0.57..8.60 rows=1
>> width=1113)
>> Index Cond: ((fulldate >=
>> '2025-01-31 09:30:00'::timestamp without time zone) AND (fulldate <
>> '2025-02-04 09:30:00'::timestamp without time zone))
>> Filter: ((hidden_by_contact IS
>> NULL) AND (subclient_id = ANY ('{13579,13580}'::integer[])) AND (id = ANY
>> ('{1381059542,1380939758,1380939757,1380939753}'::integer[])))
>> -> Index Scan using subclients2_pkey on
>> subclients (cost=0.29..8.31 rows=1 width=560)
>> Index Cond: (id =
>> companies.subclient_id)
>> Filter: (((show_3300 IS NOT TRUE)
>> AND ((companies.ep_file)::text !~ '_print3300'::text)) OR (show_3300 IS
>> TRUE))
>> -> Index Scan using temas_pkey on temas
>> (cost=0.42..8.44 rows=1 width=108)
>> Index Cond: (id = companies.main_tema_id)
>> -> Index Scan using domains_pkey on domains
>> (cost=0.42..8.44 rows=1 width=874)
>> Index Cond: (id = companies.domain_id)
>> Filter: ((p_or_d)::text = ANY
>> ('{p,d,b}'::text[]))
>> -> Index Scan using papers_pkey on papers
>> (cost=0.42..7.93 rows=1 width=33)
>> Index Cond: (id = domains.paper_id)
>> -> Index Scan using tematicas_pkey on tematicas
>> (cost=0.14..4.16 rows=1 width=19)
>> Index Cond: (id = domains.tematica_id)
>> -> Bitmap Heap Scan on special_values (cost=4.42..8.43 rows=1
>> width=2569)
>> Recheck Cond: (subclient_id = companies.subclient_id)
>> -> Bitmap Index Scan on special_values_subclient_id_idx
>> (cost=0.00..4.42 rows=1 width=0)
>> Index Cond: (subclient_id = companies.subclient_id)
>>
>> ya hice un ANALYZE.
>> La tabla companies tiene millones de filas.
>> La clave primaria de companies es "id"
>> No entiendo porque postgres no utiliza primero que nada ese índice para
>> reducir las filas de resultado, existe forma de forzar a que lo use? o es
>> correcto que no lo use?
>>
>>
>> Desde ya muchas gracias por los comentarios.
>>
>> Saludos.
>>
>> Guillermo
>>
>
^ permalink raw reply [nested|flat] 18+ messages in thread
end of thread, other threads:[~2025-02-07 13:28 UTC | newest]
Thread overview: 18+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-02-04 16:42 plan de ejecución Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-04 22:49 ` Jairo Graterón <jgrateron@gmail.com>
2025-02-05 01:33 ` Horacio Miranda <hmiranda@gmail.com>
2025-02-05 12:02 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:11 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:13 ` Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-05 12:35 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 14:13 ` Jairo Graterón <jgrateron@gmail.com>
2025-02-05 14:23 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 15:49 ` Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-06 11:33 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-06 11:56 ` Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-06 12:57 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-06 14:12 ` Álvaro Herrera <alvherre@alvh.no-ip.org>
2025-02-07 13:28 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 18:03 ` Horacio Miranda <hmiranda@gmail.com>
2025-02-06 12:26 ` Guillermo E. Villanueva <guillermovil@gmail.com>
2025-02-05 12:00 ` Guillermo E. Villanueva <guillermovil@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox