MIME-Version: 1.0
References: 
 <CAB+Nuk9NAH8MxDK9ng9G+Vvs8XAaaV7Jc=F7FWrbF8U8WWaDEw@mail.gmail.com>
In-Reply-To: 
 <CAB+Nuk9NAH8MxDK9ng9G+Vvs8XAaaV7Jc=F7FWrbF8U8WWaDEw@mail.gmail.com>
From: bruno vieira da silva <brunogiovs@gmail.com>
Date: Wed, 15 Jan 2025 13:32:27 -0500
Message-ID: 
 <CAB+Nuk-8MU0D=ghsjTnUL8xCKo356nvMuOu2ZjtqpBbBdS90bg@mail.gmail.com>
Subject: Re: Query planning read a large amount of buffers for partitioned
 tables
To: pgsql-performance@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000e8bbea062bc2e6dd"
Archived-At: 
 <https://www.postgresql.org/message-id/CAB%2BNuk-8MU0D%3DghsjTnUL8xCKo356nvMuOu2ZjtqpBbBdS90bg%40mail.gmail.com>
Precedence: bulk

--000000000000e8bbea062bc2e6dd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

correction: Is there a way to have *visibility* on its usage?

thanks

On Wed, Jan 15, 2025 at 1:29=E2=80=AFPM bruno vieira da silva <brunogiovs@g=
mail.com>
wrote:

> Hello All.
>
> On pg 17 now we have better visibility on the I/O required during query
> planning.
> so, as part of an ongoing design work for table partitioning I was
> analyzing the performance implications of having more or less partitions.
> In one of my tests of a table with 200 partitions using explain showed a
> large amount of buffers read during planning. around 12k buffers.
>
> I observed that query planning seems to have a caching mechanism as
> subsequent similar queries require only a fraction of buffers read during
> query planning.
> However, this "caching" seems to be per session as if I end the client
> session and I reconnect the same query execution will require again to re=
ad
> 12k buffer for query planning.
>
> Does pg have any mechanism to mitigate this issue ( new sessions need to
> read a large amount of buffers for query planning) ? or should I mitigate
> this issue by the use of connection pooling.
> How is this caching done? Is there a way to have viability on its usage?
> Where is it stored?
>
> Thanks
> --
> Bruno Vieira da Silva
>


--=20
Bruno Vieira da Silva

--000000000000e8bbea062bc2e6dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">correction: Is there a way to have <b>visibility</b> on it=
s usage?<div><br></div><div>thanks</div></div><br><div class=3D"gmail_quote=
 gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 1=
5, 2025 at 1:29=E2=80=AFPM bruno vieira da silva &lt;<a href=3D"mailto:brun=
ogiovs@gmail.com">brunogiovs@gmail.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hello All.=C2=
=A0</div><div><br></div><div>On pg 17 now we have better visibility on the =
I/O required during query planning.=C2=A0</div><div>so, as part of an ongoi=
ng design work for table partitioning I was analyzing the performance impli=
cations=C2=A0of having more or less partitions.</div><div>In one of my test=
s of a table with 200 partitions using explain showed a large amount of buf=
fers read during planning. around 12k buffers.</div><div><br></div><div>I o=
bserved that query planning seems to have a caching mechanism as subsequent=
 similar queries require only a fraction of buffers read during query plann=
ing.</div><div>However, this &quot;caching&quot; seems to be per session as=
 if I end the client session and I reconnect the same query execution will =
require again to read 12k buffer for query planning.</div><div><br></div><d=
iv>Does pg have any mechanism=C2=A0to mitigate this issue ( new sessions ne=
ed to read=C2=A0a large amount of buffers for query planning) ? or should I=
 mitigate this issue by the use=C2=A0of connection pooling.=C2=A0</div><div=
>How is this caching done? Is there a way to have viability=C2=A0on its usa=
ge? Where is it stored?</div><div><br></div><div>Thanks</div><span class=3D=
"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_sign=
ature"><div dir=3D"ltr">Bruno Vieira da Silva<br></div></div></div>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr">Bruno Vieira da Silva<br></div></div>

--000000000000e8bbea062bc2e6dd--