Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id E2E789FB713
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 23 Jul 2007 15:19:33 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 08737-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 23 Jul 2007 15:19:28 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 74C879FB48C
	for <pgsql-performance@postgresql.org>;
	Mon, 23 Jul 2007 15:19:30 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id l6NIJKMl001546;
	Mon, 23 Jul 2007 14:19:21 -0400 (EDT)
To: "Simon Riggs" <simon@2ndquadrant.com>
cc: "Jignesh K. Shah" <J.K.Shah@Sun.COM>, "Josh Berkus" <josh@agliodbs.com>,
	pgsql-performance@postgresql.org,
	"Alvaro Herrera" <alvherre@commandprompt.com>
Subject: Re: User concurrency thresholding: where do I look? 
In-reply-to: <1185212261.4284.270.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>
	<1185212261.4284.270.camel@ebony.site>
Comments: In-reply-to "Simon Riggs" <simon@2ndquadrant.com>
	message dated "Mon, 23 Jul 2007 18:37:41 +0100"
Date: Mon, 23 Jul 2007 14:19:20 -0400
Message-ID: <1545.1185214760@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200707/304
X-Sequence-Number: 25988

"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...

			regards, tom lane