Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Date: 2013-01-09 17:59:30
Message-ID: 20130109175930.GA25555@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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:

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-01-09 18:39:11 Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Previous Message Dimitri Fontaine 2013-01-09 17:51:12 Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers