Re: Minor optimisation of XLogInsert()

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Minor optimisation of XLogInsert()
Date: 2011-11-17 04:26:16
Message-ID: CA+TgmoZc6c_Sc4cgfPSTfn0ZUX0Z0vTML48TA=0LKkFraNkkiQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 16, 2011 at 11:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> (I wonder if we shouldn't just align every shared memory allocation to
>> 64 or 128 bytes.  It wouldn't waste much memory and it would make us
>> much more resistant to performance changes caused by minor
>> modifications to the shared memory layout.)
>
> I could get behind this idea if we had a reasonably clear idea of the
> hardware's cache line width, but AFAIK there is no portable way to
> identify that.  (This is a pretty fatal objection to Simon's original
> patch as well...)

I don't think it's very important to know the exact size. As far as I
can tell, x64 is 64 bytes and Itanium and Power are 128 bytes. If you
optimize for those, you'll also handle any smaller size (that's a
power of two, without which a lot of things we do are wrongheaded)
without wasting much memory. If you run into hardware with a giant
256-byte or large cache line, you might have some sharing, but you
can't win 'em all.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2011-11-17 04:28:41 Re: [PATCH] Support for foreign keys with arrays
Previous Message Pavan Deolasee 2011-11-17 04:16:18 Re: FlexLocks