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 18:30:48 |
Message-ID: | 1185215448.4284.295.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, 2007-07-23 at 14:19 -0400, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jignesh K. Shah | 2007-07-24 04:09:00 | Second SpecJAppserver2004 with PostgreSQL |
Previous Message | Tom Lane | 2007-07-23 18:19:20 | Re: User concurrency thresholding: where do I look? |