Simon Riggs wrote:
On Tue, 2008-10-28 at 16:22 +0200, Heikki Linnakangas wrote:
Arbitrarily, if after a
heap insert/update there's less than 20% of free space on the page,
the FSM is updated. Compared to updating it every time, that saves a
lot of overhead, while doing a pretty good job at marking full pages
as full in the FSM. My first thought was to update the FSM if there
isn't enough room on the page for a new tuple of the same size as the
one just
inserted; that would be pretty close to the logic we have during
normal
operation, where the FSM is updated when the tuple that we're about
to
insert doesn't fit on the page. But because we don't know the
fillfactor
during recovery, I don't think we can do reliably.
With HOT, we tend to hover around the nearly-full state, so this seems
like it will trigger repeatedly.
Hmm, true. Perhaps we should skip updating the FSM on HOT updates. After
recovery, the new HOT-updated tuples are prunable anyway, so for
inserting a new tuple, the page is almost as good as it was before the
HOT update.
Is it possible that we could put an extra field onto a heap_clean record
to show remaining space. We would use it only for VACUUMs, not HOT, just
as we do now.
Sure, we could do that. I'm more worried about "killing" the pages from
the FSM that are full, though, than keeping track of pages with plenty
of free space accurately.
I wonder if there is merit in having an XLogInsertMulti() which inserts
multiple records in a batch as a way of reducing WALInsertLock traffic.
It might be possible to piggyback FSM records onto the main heap
changes.
Umm, in the version that was finally committed, FSM doesn't generate any
extra WAL records (except for truncation).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
