| 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: | Whole Thread | Raw Message | 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 |