Re: [PATCHES] COPY with no WAL, in certain circumstances

On Tue, 2007-01-09 at 16:31 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > ...continuing this discussion about setting HEAP_XMIN_COMMITTED...
> 
> >> BTW, a sufficient counterexample for that kluge is that neither SPI or
> >> SQL-function execution use a separate portal for invoked commands.
> 
> > What would the best/acceptable way be to test for this condition?
> 
> My opinion is that the only reliable answer would be to find a way not
> to have to test.  Tuples entered by your own transaction are normally
> considered good by tqual.c anyway, and thus I think we might be pretty
> close to having it Just Work, but you'd have to go through all the cases
> in tqual.c and see if any don't work.

I agree we could get this to Just Work by altering
HeapTupleSatisfies...() functions so that their first test is
if (TransactionIdIsCurrentTransactionId(xvac))

rather then
if (!(tuple->t_infomask & HEAP_XMIN_COMMITTED))

I had ruled that out, unconsciously prefering the localised check in
COPY, but I agree that the test was too complex.

Taking this direct approach does have a lot of promise: Looks like
HeapTupleSatisfiesSnapshot() currently does 4 if tests to check that an
undeleted row is visible, and all other paths do much more work.
Increasing the number of checks to 5 might not hurt that much. The
branch prediction would work well for it, since when you are the
CurrentTransactionId the test would pass 100% and when you're not the
branch would fail 100% of the time, so the CPU would react to it
positively I think.

I'll run some tests and see if there's a noticeable difference.

> The other point is that to make such an optimization you have to
> consider the subtransaction history.  For WAL you only have to know that
> the table will disappear if the top-level transaction fails, but to
> pre-set commit bits requires being sure that the table will disappear
> if the current subxact fails --- not the same thing at all.

Right, you reminded me of that on the other part of the thread.

It seems straightforward to put a test into COPY that the optimization
will only work if you're in the Xid that made the relfilenode change. 

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com