Re: [PATCH] Let's get rid of the freelist and the buffer_strategy_lock

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Burd <greg(at)burd(dot)me>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: [PATCH] Let's get rid of the freelist and the buffer_strategy_lock
Date: 2025-09-05 18:36:59
Message-ID: CA+TgmoYw2psUKOA0egV20_emsHBbFCpa9egvkSE6fPYAj126_Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 11, 2025 at 3:48 PM Greg Burd <greg(at)burd(dot)me> wrote:
> I briefly considered how one might use what was left after surgery to produce some similar boolean signal to no avail. I think that autoprewarm was simply trying to at most warm NBuffers then stop. The freelist at startup was just a convenient thing to drain and get that done. Maybe I'll try adapting autoprewarm to consider that global instead.

My concern had been that while autoprewarm was running, other system
activity could already have started and been filling up
shared_buffers. By considering whether there were actually free
buffers remaining, it would prewarm less in that case.

I'm not saying that was the perfect idea, I'm just telling you what I
was thinking at the time.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-09-05 18:43:09 Re: [PATCH] Add tests for Bitmapset
Previous Message Ashutosh Sharma 2025-09-05 18:34:56 Re: Improve pg_sync_replication_slots() to wait for primary to advance