Re: Memory Alignment in Postgres

From: Arthur Silva <arthurprs(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory Alignment in Postgres
Date: 2014-09-11 17:54:36
Message-ID: CAO_YK0WkZY1e7Nq6Xj0CkAD3o5iFSDJg198_BC4o4CGjsfztbw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 11, 2014 at 12:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> > Be advised of the difficulties you are going to face here. Assuming
> > for a second there is no reason not to go unaligned on Intel and there
> > are material benefits to justify the effort, that doesn't necessarily
> > hold for other platforms like arm/power.
>
> Note that on many (most?) non-Intel architectures, unaligned access is
> simply not an option. The chips themselves will throw SIGBUS or
> equivalent if you try it. Some kernels provide signal handlers that
> emulate the unaligned access in software rather than killing the process;
> but the performance consequences of hitting such traps more than very
> occasionally would be catastrophic.
>

> Even on Intel, I'd wonder what unaligned accesses do to atomicity
> guarantees and suchlike. This is not a big deal for row data storage,
> but we'd have to be careful about it if we were to back off alignment
> requirements for in-memory data structures such as latches and buffer
> headers.
>
> Another fun thing you'd need to deal with is ensuring that the C structs
> we overlay onto catalog data rows still match up with the data layout
> rules.
>
> On the whole, I'm pretty darn skeptical that such an effort would repay
> itself. There are lots of more promising things to hack on.
>
> regards, tom lane
>

Indeed I don't know any other architectures that this would be at an
option. So if this ever moves forward it must be turned on at compile time
for x86-64 only. I wonder how the Mysql handle their rows even on those
architectures as their storage format is completely packed.

If we just reduced the alignment requirements when laying out columns in
the rows and indexes by reducing/removing padding -- typalign, it'd be
enough gain in my (humble) opinion.

If you think alignment is not an issue you can see saving everywhere, which
is kinda insane...

I'm unsure how this equates in patch complexity, but judging by the
reactions so far I'm assuming a lot.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-09-11 18:08:27 Re: proposal (9.5) : psql unicode border line styles
Previous Message Alexey Klyukin 2014-09-11 17:46:46 Re: implement subject alternative names support for SSL connections