Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Oh, also the inval.c code now is saving a lot of pfrees at each
> transaction end.
Nope, that's not it; the old code actually did no retail pfree's
anyway --- I just diked out what was really dead code.
Besides which, pgbench doesn't do any catalog updates in its main loop,
and so there shouldn't be anything for inval.c to do anyhow.
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.
> By the way, thank you very much for the code review. The commit message
> said "with some help from," but it actually should have been something
> like "more than half of the patch rewritten by." Lots of things are
> much simpler and of course a lot of bugs are gone.
And, no doubt, some new ones introduced ;-). I have a long list of
things we still need to look at, which I will post as soon as I've
cleaned it up into a readable form.
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. And I think you sent me one other
patch recently that didn't make it into this commit, either.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
