Re: Low hanging fruit in lazy-XID-assignment patch? - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Low hanging fruit in lazy-XID-assignment patch?
Date
Msg-id 1189150574.4175.447.camel@ebony.site
Whole thread Raw
In response to Re: Low hanging fruit in lazy-XID-assignment patch?  ("Florian G. Pflug" <fgp@phlo.org>)
Responses Re: Low hanging fruit in lazy-XID-assignment patch?
List pgsql-hackers
On Fri, 2007-09-07 at 06:36 +0200, Florian G. Pflug wrote:
> Tom Lane wrote:
> > "Florian G. Pflug" <fgp@phlo.org> writes:
> >> So I believe you're right, and we can skip taking the lock in the no
> >> xid case 

Sounds good.

> - I actually think with just a little bit of more work, we
> >> can go even further, and get rid of the ReadNewTransactionId() call
> >> completely during snapshotting.
> > 
> > [ squint... ]  This goes a bit far for me.  In particular, I think this
> > will fail in the edge case when there are no live XIDs visible in
> > ProcArray.  You cannot go back and do ReadNewTransactionId afterward,
> > at least not without re-scanning the ProcArray a second time, which
> > makes it at best a questionable win.
> 
> Why would it?

I think the additional suggestion goes a bit too far. You may be right,
but I don't want to change the transaction system in advanced ways this
close to the next release. We may have difficulty spotting bugs in that
thinking during beta.

lazy XID assignment will reduce the number of times
GetNextTransactionId() is called and if we also avoid taking the
ProcArrayLock for CommitTransaction() then we will have significantly
reduced contention for mixed workloads (i.e. most real ones).

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Phil
Date:
Subject: Installation problem and a question
Next
From: "Heikki Linnakangas"
Date:
Subject: GIN readme is out of date