On Mon, Aug 16, 2021 at 10:35:45AM -0700, Peter Geoghegan wrote:
> I have suspected that there are serious design issues with the FSM
> (and related heapam code like hio.c) for several years now [1]. This
> has a lot to do with the experience of using Jan Wieck's BenchmarkSQL
> implementation of TPC-C [2][3][4]. It clearly makes Postgres exhibit
> pathological performance issues, especially heap fragmentation.
OK, here is my feedback. First, I understand the space
reservation/soccer idea, but I am also concerned that adding space
reservation could improve some things and make others worse.
Second, let's look at a concrete example, and see how it can be improved
more simply. As I understand it, there are three operations that need
free space:
1. INSERT/COPY
2. UPDATE where there is insufficient space on the page of the
old row
3. UPDATE where there is sufficient page space
The third option already can use the existing page for a HOT update, so
the FSM doesn't matter. For 1 & 2, suppose you have a table with 10 8k
pages, all 80% full. As I understand it, the first page will go from
80% to 81%, then the next row addition will take the second page from
80% to 81%, until all pages are 81%, and then it starts over again. Is
that accurate? Is that the non-temporal memory issue you are concerned
about? Doesn't spreading the new rows out increase the ability to do
HOT updates?
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
