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"
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 |