Hello, Your explanation aligns with the idea I had that having more
shared_buffers and connection pooling are very important in the context of
the partitioned tables.
Thanks. Regards.
On Tue, Feb 18, 2025 at 7:16 AM David Rowley wrote:
> On Tue, 18 Feb 2025 at 09:18, bruno vieira da si
nevermind. The query plan was done on test data with 50 partitions.
Sorry for the confusion.
On Mon, Feb 17, 2025 at 3:25 PM bruno vieira da silva
wrote:
> Well, the query plans were generated with pg 17.3. and the buffer usage
> was half.
> did pg 17.3 had any fixes to reduce the
Well, the query plans were generated with pg 17.3. and the buffer usage was
half.
did pg 17.3 had any fixes to reduce the planning buffer usage?
On Mon, Feb 17, 2025 at 3:18 PM bruno vieira da silva
wrote:
> Hello, I did a more comprehensive test with a different number of
> partitions
d = (InitPlan 1).col1)
Buffers: shared hit=2 read=1
Planning:
Buffers: shared hit=5
Planning Time: 0.604 ms
Execution Time: 10.011 ms
(159 rows)
On Thu, Jan 16, 2025 at 9:56 AM bruno vieira da silva
wrote:
> Hello, Thanks David.
>
> this pg test deployment. anyways I did
Hello, Thanks David.
this pg test deployment. anyways I did a vacuum full on the db. and the
number of buffers read increased a bit.
On Wed, Jan 15, 2025 at 3:01 PM David Rowley wrote:
> On Thu, 16 Jan 2025 at 07:29, bruno vieira da silva
> wrote:
> > On pg 17 now we have bette
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
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 tab
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
