Skip site navigation (1) Skip section navigation (2)

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

From: Andres Freund <andres(at)anarazel(dot)de>
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:02:47
Message-ID: 20130109170247.GC11725@awork2.anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On 2013-01-09 11:57:35 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2013-01-09 11:37:46 -0500, Tom Lane wrote:
> >> I agree that what dirmod is doing is pretty ugly, but it's localized
> >> enough that I don't care particularly.  (Really, the only reason it's
> >> a hack and not The Solution is that at the moment there's only one
> >> file doing it that way.  A trampoline function for use only by code
> >> that needs to work in both frontend and backend isn't an unreasonable
> >> idea.)
> 
> > Well, after the patch the trampoline function would be palloc() itself.
> 
> 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.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2013-01-09 17:05:45
Subject: Re: PL/perl should fail on configure, not make
Previous:From: Alvaro HerreraDate: 2013-01-09 16:58:29
Subject: Re: Event Triggers: adding information

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group