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"
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
