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