Re: Freeze avoidance of very large table.

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