Re: [PATCHES] COPY with no WAL, in certain circumstances - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [PATCHES] COPY with no WAL, in certain circumstances
Date
Msg-id 1168448289.3951.427.camel@silverbirch.site
Whole thread Raw
In response to Re: [PATCHES] COPY with no WAL, in certain circumstances  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2007-01-10 at 10:37 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > I agree we could get this to Just Work by altering
> > HeapTupleSatisfies...() functions so that their first test is
> >     if (TransactionIdIsCurrentTransactionId(xvac))

Oh? Sorry, I meant xmin not xvac at that point. Cut N Paste thinko.

> > rather then
> >     if (!(tuple->t_infomask & HEAP_XMIN_COMMITTED))
> 
> Huh?  That doesn't make any sense at all.  xvac wouldn't normally be
> valid.


> I don't want to put TransactionIdIsCurrentTransactionId into the main
> path of the tqual routines if at all possible; it's not an especially
> cheap test, particularly if deeply nested in subtransactions.

Phew, well I'm relieved. Such a mainline change did make me nervous.

> This would require rejiggering snapshots to include our own xid, see
> comment for XidInSnapshot.  That would add some distributed cost to
> executions of XidInSnapshot for recently-committed tuples, but it would
> avoid adding any cycles to the path taken for tuples committed before
> the xmin horizon, which is the normal case that has to be kept fast.
> 
> Haven't looked at whether an equivalent hack is possible for the other
> tqual routines.

Will check, thanks.

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




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Building libpq/psql with Borland BCC5
Next
From: "Simon Riggs"
Date:
Subject: Re: Mark/Restore and avoiding RandomAccess sorts