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: 20040701130711.GA12530@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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]dcc.uchile.cl>)
"Para tener más hay que desear menos"

In response to

Responses

Browse pgsql-hackers by date

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