On 4/22/15 1:24 PM, Robert Haas wrote:
I keep coming back to the idea of treating any page that is marked as
all-visible as frozen, and deferring freezing until the page is again
modified.  The big downside of this is that if the page is set as
all-visible and then immediately thereafter modified, it sucks to have
to freeze when the XIDs in the page are still present in CLOG.  But if
we could determine from the LSN that the XIDs in the page are new
enough to still be considered valid, then we could skip freezing in
those cases and only do it when the page is "old".  That way, if
somebody zeroed out the LSN (why, oh why?) the worst that would happen
is that we'd do some extra freezing when the page was next modified.

Maybe freezing a page as part of making it not all-visible wouldn't be that horrible, even without LSN.

For one, we already know that every tuple is visible, so no MVCC checks needed. That's probably a significant savings over current freezing.

If we're marking a page as no longer all-visible, that means we're already dirtying it and generating WAL for it (likely including a FPI). We may be able to consolidate all of this into a new WAL record that's a lot more efficient than what we currently do for freezing. I suspect we wouldn't need to log each TID we're freezing, for starters. Even if we did though, we could at least combine all that into one WAL message that just contains an array of TIDs or LPs.

<ponders...> I think we could actually proactively freeze tuples during vacuum too, at least if we're about to mark the page as all-visible. Though, with Robert's HEAP_XMIN_FROZEN change we could be a lot more aggressive about freezing during VACUUM, certainly for pages we're already dirtying, especially if we can keep the WAL cost of that down.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to