Re: The Free Space Map: Problems and Opportunities

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: The Free Space Map: Problems and Opportunities
Дата
Msg-id CA+TgmobRa282c9NLhYiiVdq4aG2pxq9JpnVz6isYs=eEPHkUhQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: The Free Space Map: Problems and Opportunities  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: The Free Space Map: Problems and Opportunities  (Peter Geoghegan <pg@bowt.ie>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: NAMEDATALEN increase because of non-latin languages
Следующее
От: Robert Haas
Дата:
Сообщение: Re: replay of CREATE TABLESPACE eats data at wal_level=minimal