Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Suggestions:
1) remove WAL logging. I think that FSM record should be recovered
during processing of others WAL records (like insert, update).
Probably only we need full page write on first modification after
checkpoint.
Hmm, we don't have the infrastructure to do that, but I guess it's
doable. In case of a crash, the FSM information after recovery wouldn't
obviously be up-to-date. And the FSM information in a warm standby would
also lag behind.
One option would be to put RecordPageWithFreeSpace() calls into
heap_redo, so that the FSM would be updated based on the WAL records we
write anyway.
Yes, it seems to be a good place.
I think we'd still need to WAL log operations that decrease the amount
of free space on page. Otherwise, after we have partial vacuum, we might
never revisit a page, and update the FSM, even though there's usable
space on the page, leaving the space forgotten forever.
I think, if you update actual free space on each page which is recorded in the
WAL then you should have actual FSM. Something like this:
RecordPageWithFreeSpace(PageGetFreeSpace(..))
<snip>
Other important test cases are various bulk insert kind of tests.
Parallel bulkload could be problem. Another problem could be CREATE TEMP TABLE
command which updates catalog, which is usually small.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
