From: | bruno vieira da silva <brunogiovs(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Query planning read a large amount of buffers for partitioned tables |
Date: | 2025-01-15 18:32:27 |
Message-ID: | CAB+Nuk-8MU0D=ghsjTnUL8xCKo356nvMuOu2ZjtqpBbBdS90bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
correction: Is there a way to have *visibility* on its usage?
thanks
On Wed, Jan 15, 2025 at 1:29 PM bruno vieira da silva <brunogiovs(at)gmail(dot)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 read
> 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
>
--
Bruno Vieira da Silva
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2025-01-15 20:01:33 | Re: Query planning read a large amount of buffers for partitioned tables |
Previous Message | bruno vieira da silva | 2025-01-15 18:29:30 | Query planning read a large amount of buffers for partitioned tables |