Re: getting rid of freezing - Mailing list pgsql-hackers

On Sat, May 25, 2013 at 6:14 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> One thought I had is that it might be beneficial to freeze when a page
>> ceases to be all-visible, rather than when it becomes all-visible.
>> Any operation that makes the page not-all-visible is going to emit an
>> FPI anyway, so we don't have to worry about torn pages in that case.
>> Under such a scheme, we'd have to enforce the rule that xmin and xmax
>> are ignored for any page that is all-visible; and when a page ceases
>> to be all-visible, we have to go back and really freeze the
>> pre-existing tuples.  I think we might be able to use the existing
>> all_visible_cleared/new_all_visible_cleared flags to trigger this
>> behavior, without adding anything new to WAL at all.
>
> I like the idea but it would mean we'd have to freeze in the
> foreground path rather in a background path.

That's true, but I think with this approach it would be really cheap.
The overhead of setting a few bits in a page is very small compared to
the overhead of emitting a WAL record.  We'd have to test it, but I
wouldn't be surprised to find the cost is too small to measure.

> Have we given up on the double buffering idea to remove FPIs
> completely? If we did that, then this wouldn't work.

I don't see why those things are mutually exclusive.  What is the relationship?

> Anyway, I take it the direction of this idea is that "we don't need a
> separate freezemap, just use the vismap". That seems to be forcing
> ideas down a particular route we may regret. I'd rather just keep
> those things separate, even if we manage to merge the WAL actions for
> most of the time.

Hmm.  To me it seems highly desirable to merge those things, because
they're basically the same thing.  The earliest time at which we can
freeze a tuple is when it's all-visible, and the only argument I've
ever heard for waiting longer is to preserve the original xmin for
forensic purposes, which I think we can do anyway.  I have posted a
patch for that on another thread.  I don't like having two separate
concepts where one will do; I think the fact that it is structured
that way today is mostly an artifact of one setting being page-level
and the other tuple-level, which is a thin excuse for so much
complexity.

> I think the right way is actually to rethink and simplify all this
> complexity of Freezing/Pruning/Hinting/Visibility

I agree, but I think that's likely to have to wait until we get a
pluggable storage API, and then a few years beyond that for someone to
develop the technology to enable the new and better way.  In the
meantime, if we can eliminate or even reduce the impact of freezing in
the near term, I think that's worth doing.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company