Re: The Free Space Map: Problems and Opportunities - Mailing list pgsql-hackers

From Robert Haas
Subject Re: The Free Space Map: Problems and Opportunities
Date
Msg-id CA+TgmobRa282c9NLhYiiVdq4aG2pxq9JpnVz6isYs=eEPHkUhQ@mail.gmail.com
Whole thread Raw
In response to Re: The Free Space Map: Problems and Opportunities  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: The Free Space Map: Problems and Opportunities  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Tue, Aug 17, 2021 at 8:31 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Lets say that VACUUM puts a non-zero usable amount of free space in
> the FSM for a page that it marks all-visible/all-frozen at the same
> time -- this is possible today, of course. To me this seems
> contradictory, at least when there isn't much space -- which I believe
> is common. It's at least a minor waste to set the VM bit.

It seems to me that you are talking about the VM bit but making an
argument that is more applicable to the FSM. If we think that the
small amount of freespace in the page is going to result in the page
being dirtied repeatedly as it cycles through a bunch of different
tuples none of which stick around long term, then we might not want to
advertise the freespace in the FSM, or we might want the FSM to
disregard the fact that a small amount of freespace is present there.
However, if we do that, then we certainly want to also set the VM bit.
Otherwise, we've got a page that we've effectively quiesced, by
refusing to reuse the freespace, but the VM doesn't know that, so
future index-only scans and VACUUM operations are penalized.

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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: NAMEDATALEN increase because of non-latin languages
Next
From: Robert Haas
Date:
Subject: Re: replay of CREATE TABLESPACE eats data at wal_level=minimal