On 2013-01-09 12:32:20 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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:
#101646.763208 101350.361595 101421.425668 101571.211688 101862.172051 101449.857665
#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
Anyway, we can use a macro instead, I don't think its that important.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
In response to
pgsql-hackers by date
|Next:||From: Josh Berkus||Date: 2013-01-09 18:39:11|
|Subject: Re: proposal: Set effective_cache_size to greater of .conf
|Previous:||From: Dimitri Fontaine||Date: 2013-01-09 17:51:12|
|Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers|