Re: Deferring some AtStart* allocations? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Deferring some AtStart* allocations?
Date
Msg-id 20140630012207.GI21422@awork2.anarazel.de
Whole thread Raw
In response to Re: Deferring some AtStart* allocations?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-06-29 21:12:49 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-06-29 19:52:23 -0400, Tom Lane wrote:
> >> Andres Freund <andres@2ndquadrant.com> writes:
> >>> Why aren't we delaying allocations in e.g. AtStart_Inval(),
> >>> AfterTriggerBeginXact() to when the data structures are acutally used?
> >> 
> >> Aren't we?  Neither of those would be doing much work certainly.
> 
> > They are perhaps not doing much in absolute terms, but it's a fair share
> > of the processing overhead for simple statements. AfterTriggerBeginXact()
> > is called unconditionally from StartTransaction() and does three
> > MemoryContextAlloc()s. AtStart_Inval() one.
> > I think they should just be initialized whenever the memory is used?
> > Doesn't look too complicated to me.
> 
> Meh.  Even "SELECT 1" is going to be doing *far* more pallocs than that to
> get through raw parsing, parse analysis, planning, and execution
> startup.

The quick test I ran used prepared statements - there the number of
memory allocations is *much* lower...

> If you can find a few hundred pallocs we can avoid in trivial queries,
> it would get interesting; but I'll be astonished if saving 4 is measurable.

I only noticed it because it shows up in profiles. I doubt it'll even
remotely be noticeable without using prepared statements, but a lot of
people do use those.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: idle_in_transaction_timeout
Next
From: Fujii Masao
Date:
Subject: Re: Cluster name in ps output