Re: RFC: Making TRUNCATE more "MVCC-safe" - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: RFC: Making TRUNCATE more "MVCC-safe"
Date
Msg-id CA+U5nMJ4Srx6i3HUqODB3hPr0a6nVAHHsFrmgnpg12bkBiEHLQ@mail.gmail.com
Whole thread Raw
In response to Re: RFC: Making TRUNCATE more "MVCC-safe"  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: RFC: Making TRUNCATE more "MVCC-safe"  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Mar 7, 2012 at 5:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 7, 2012 at 10:26 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Wed, Mar 7, 2012 at 2:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> All true.
>>
>> So gentlemen, do we think this is worth pursuing further for this release?
>>
>> I'm sure usual arguments apply all round, so I'll skip that part.
>
> This patch is awfully late to the party, but if we can nail it down
> reasonably quickly I guess I'd be in favor of slipping something in.

Cool

> I am not thrilled with the design as it stands, but bulk loading is a
> known and serious pain point for us, so it would be awfully nice to
> improve it.  I'm not sure whether we should only go as far as setting
> HEAP_XMIN_COMMITTED or whether we should actually try to mark the
> tuples with FrozenXID.  The former has the advantage of (I think) not
> requiring any other changes to preserve MVCC semantics while the
> latter is, obviously, a bigger performance improvement.

It's the other way around. Setting to FrozenTransactionId makes the
test in XidInMVCCSnapshot() pass when accessed by later commands in
the same transaction. If we just set the hint we need to play around
to get it accepted. So the frozen route is both best for performance
and least impact on fastpath visibility code. That part of the code is
solid.

The only problem is the visibility from older snapshots, we just
need/desire a better place to put the test. So I'll finish that off.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: poll: CHECK TRIGGER?
Next
From: Pavel Stehule
Date:
Subject: Re: poll: CHECK TRIGGER?