pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
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 19:30:48 +0100
Message-ID: <1185215448.4284.295.camel@ebony.site> (raw)
In-Reply-To: <1545.1185214760@sss.pgh.pa.us>
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>
	<1185212261.4284.270.camel@ebony.site>
	<1545.1185214760@sss.pgh.pa.us>

On Mon, 2007-07-23 at 14:19 -0400, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > 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.
> 
> Ah.  I was seeing it as 6600 bytes on HPPA and 6608 on x86_64, but
> I forgot that both of those architectures have MAXALIGN = 8.  On a
> MAXALIGN = 4 machine, MaxIndexTuplesPerPage will be significantly
> larger, leading to larger BTScanPosData.
> 
> Not sure it's worth fooling with, given that these days almost everyone
> who's seriously concerned about performance is probably using 64bit
> hardware.  One less malloc cycle per indexscan is never going to be a
> measurable savings anyway...

Oh sure, I was thinking to avoid Solaris' mutex by avoiding malloc()
completely.

-- 
  Simon Riggs
  EnterpriseDB  http://www.enterprisedb.com




view thread (58+ messages)  latest in thread

Message-ID: <1185215448.4284.295.camel@ebony.site>
Permalink:  ../1185215448.4284.295.camel@ebony.site/
Also on:    postgresql.org/message-id/1185215448.4284.295.camel@ebony.site

 · 

reply
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: <1185215448.4284.295.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