Re: shared buffers

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Marc Millas <marc(dot)millas(at)mokadb(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: shared buffers
Date: 2025-04-25 22:46:15
Message-ID: 8b2525bcc0c714603cc4f44a686b8b0e4659ac92.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 2025-04-25 at 15:42 +0200, Marc Millas wrote:
> got something strange to me:
> Same db ie. same data, around 1.2TB,one on pg13, one on pg16
> same 16 GB of shared_buffers,
> I am the single user.
> both have track_io_timing on
>
> on pg13, if I run a big request with explain (analyze,buffers), 
> I see around 6 GB read
> if I do rerun the very same request, no more read(s), all data in the shared buffers cache. fine
> If I check with pg_buffercache what's in it, I see the biggest tables of my request within
> the biggest users (in number of blocks used). All this is fine.
>
> next, if I do the very same on the pg16 machine, whatever the number of times I rerun the
> explain (analyze, buffers) of the same request, each time, the explain shows the same volume
> of reads. again and again.
> If I check with pg_buffercache, the set of objects stay the same, WITHOUT the objects of my
> request, just like if those objects where sticky.

I can't see the plans, so I can only guess.

Perhaps the v16 plan uses a sequential scan on a table that is more than a quarter of
shared_buffers in size, so that PostgreSQL uses a ring buffer to read it instead of
blowing out more than a quarter of its buffer cache.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Igor Korot 2025-04-26 03:24:49 How to properly fix memory leak
Previous Message Marc Millas 2025-04-25 16:13:14 Re: shared buffers