Skip site navigation (1) Skip section navigation (2)

Re: Performance with new nested-xacts code

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Performance with new nested-xacts code
Date: 2004-07-01 13:07:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jul 01, 2004 at 08:51:59AM -0400, Tom Lane wrote:

> The only thing that's occurred to me since last night is that I
> simplified the data structures in trigger.c enough to get rid of
> a separate memory context for them.  That means one less
> MemoryContextCreate/Delete per transaction cycle.  It's tough to
> believe that that's a 10% gain ... but OTOH, with --enable-cassert
> turned on, there's a lot of per-context overhead invested in
> memory checking.
> Were your numbers also taken with --enable-cassert?  It might be
> instructive to compare numbers taken without.

Ah, yes, it was with asserts enabled.  I'll try again.

> I did not yet incorporate the localbuf changes you sent; I think we
> should first decide what our theory is about cursors, which will
> determine whether we need to change bufmgr.c.  There's no point in
> cloning that code until it's right.

Well, my opinion is that cursors and other resources should at least be
usable from a inner subtransaction in its parent -- because if that
can't be done we are wasting some of the benefits, because we can't just
"stick everything in a subtransaction" to be able to retry if it fails.  
It is a pity that we can't roll back FETCH or lo_close() but at least we
can keep them declared/open across a subtransaction commit.

So I think we should only be releasing resources and restoring refcounts
at subtransaction abort, not commit -- and of course we would only
complain about nonzero refcounts for main transaction commit.

I have changes for this in the relcache and catcache code because it was
needed to make large objects behave; I'll do it for bufmgr too.  (Anyway
there's something strange about large objects, because at main
transaction commit the locking code says "corrupted proclock table" -- I
haven't been able to figure out why).

> And I think you sent me one other patch recently that didn't make it
> into this commit, either.

Yes, it was the password file management.  But it was untested; let me
do that first (we need some docs on that file).

Alvaro Herrera (<alvherre[a]>)
"Para tener más hay que desear menos"

In response to


pgsql-hackers by date

Next:From: Dennis BjorklundDate: 2004-07-01 13:19:32
Subject: Re: Bug with view definitions?
Previous:From: Tom LaneDate: 2004-07-01 12:51:59
Subject: Re: Performance with new nested-xacts code

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group