On 2013-01-09 12:32:20 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2013-01-09 11:57:35 -0500, Tom Lane wrote: > >> My objection is that you're forcing *all* backend code to go through > >> the trampoline. That probably has a negative impact on performance, and > >> if you think it'll get committed without a thorough proof that there's > >> no such impact, you're mistaken. Perhaps you're not aware of exactly > >> how hot a hot-spot palloc is? It's not unlikely that this patch could > >> hurt backend performance by several percent all by itself. > > > There is no additional overhead except some minor increase in code size. > > If you look at the patch palloc() now simply directly calls > > CurrentMemoryContext->methods->alloc. So there is no additional function > > call relative to the previous state. > > Apparently we're failing to communicate, so let me put this as clearly > as possible: an unsupported assertion that this patch has zero cost > isn't worth the electrons it's written on.
Well, I *did* benchmark it as noted elsewhere in the thread, but thats obviously just machine (E5520 x 2) with one rather restricted workload (pgbench -S -jc 40 -T60). At least its rather palloc heavy. Here are the numbers: before: #101646.763208 101350.361595 101421.425668 101571.211688 101862.172051 101449.857665 after: #101553.596257 102132.277795 101528.816229 101733.541792 101438.531618 101673.400992 So on my system if there is a difference, its positive (0.12%). > In any case it's not clear to me why duplicating code like that is a > less ugly approach than having different macro definitions for frontend > and backend. Imo its better abstracted and more consistent (pfree() is not a macro, palloc() is) and actually makes it easier to redirect code somewhere else. It also opens the door for exposing less knowledge in utils/palloc.h. Anyway, we can use a macro instead, I don't think its that important. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers