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

Re: User concurrency thresholding: where do I look?

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>,"Josh Berkus" <josh(at)agliodbs(dot)com>,<pgsql-performance(at)postgresql(dot)org>,"Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Subject: Re: User concurrency thresholding: where do I look?
Date: 2007-07-23 17:37:41
Message-ID: 1185212261.4284.270.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-performance
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(at)2ndquadrant(dot)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


In response to

Responses

pgsql-performance by date

Next:From: A. KretschmerDate: 2007-07-23 17:37:49
Subject: Re: disable archiving
Previous:From: Alvaro HerreraDate: 2007-07-23 17:34:20
Subject: Re: disable archiving

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