Re: The Free Space Map: Problems and Opportunities

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jan Wieck <jan(at)wi3ck(dot)info>, Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: The Free Space Map: Problems and Opportunities
Date: 2021-08-18 14:45:08
Message-ID: CA+TgmobRa282c9NLhYiiVdq4aG2pxq9JpnVz6isYs=eEPHkUhQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 17, 2021 at 8:31 PM Peter Geoghegan <pg(at)bowt(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-08-18 14:47:24 Re: replay of CREATE TABLESPACE eats data at wal_level=minimal
Previous Message Peter Eisentraut 2021-08-18 14:43:23 Re: NAMEDATALEN increase because of non-latin languages