From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jignesh K. Shah <J.K.Shah@Sun.COM>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-performance@postgresql.org
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Subject: Re: User concurrency thresholding: where do I look?
Date: Mon, 23 Jul 2007 18:37:41 +0100
Message-ID: <1185212261.4284.270.camel@ebony.site> (raw)
In-Reply-To: <1185205663.4284.249.camel@ebony.site>
References: <200707190828.59088.josh@agliodbs.com>
<200707191819.13899.josh@agliodbs.com>
<15685.1184895926@sss.pgh.pa.us>
<200707192138.39679.josh@agliodbs.com>
<46A0FA31.2080208@sun.com>
<12002.1184955831@sss.pgh.pa.us>
<46A1055F.9010304@sun.com>
<12445.1184958793@sss.pgh.pa.us>
<46A11116.5030905@sun.com>
<14909.1184962561@sss.pgh.pa.us>
<46A1205B.8010205@sun.com>
<15343.1184965054@sss.pgh.pa.us>
<1185180668.4284.149.camel@ebony.site>
<23848.1185199901@sss.pgh.pa.us>
<1185201556.4284.243.camel@ebony.site>
<25095.1185202498@sss.pgh.pa.us>
<1185205663.4284.249.camel@ebony.site>
On Mon, 2007-07-23 at 16:48 +0100, Simon Riggs wrote:
> On Mon, 2007-07-23 at 10:54 -0400, Tom Lane wrote:
> > "Simon Riggs" <simon@2ndquadrant.com> writes:
> > > I looked at this last May and my notes say "ExecutorState". I guess that
> > > was wrong, but my analysis showed there was a single malloc of 8228
> > > bytes happening once per query during my tests.
> >
> > Well, if you can track down where it's coming from, we could certainly
> > hack the containing context's parameters. But EState's not it.
>
> Well, I discover there is an allocation of 8232 (inflation...) made once
> per statement by a memory context called... ExecutorState. Still not
> sure exactly which allocation this is, but its definitely once per
> statement on pgbench, which should narrow it down. Plan, query etc?
>
> I don't see a way to hack the allocation, since the max chunk size is
> 8K.
It is the allocation of BTScanOpaqueData called from btrescan() in
nbtree.c
currPos and markPos are defined as BTScanPosData, which is an array of
BTScanPosItems. That makes BTScanOpaqueData up to 8232 bytes, which
seems wasteful since markPos is only ever used during merge joins. Most
of that space isn't even used during merge joins either, we just do that
to slightly optimise the speed of the restore during merge joins.
Seems like we should allocate the memory when we do the first mark.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: simon@2ndquadrant.com, tgl@sss.pgh.pa.us, J.K.Shah@Sun.COM, josh@agliodbs.com, alvherre@commandprompt.com
Subject: Re: User concurrency thresholding: where do I look?
In-Reply-To: <1185212261.4284.270.camel@ebony.site>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox