Re: Memory Alignment in Postgres

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Arthur Silva <arthurprs(at)gmail(dot)com>
Cc: 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 15:17:16
Message-ID: CAHyXU0yxu+kBEc=r6jy-6ccR6r8RPwRsfMYnxwiMY--evKmaaA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 11, 2014 at 8:32 AM, Arthur Silva <arthurprs(at)gmail(dot)com> wrote:
>
> On Wed, Sep 10, 2014 at 12:43 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> On Tue, Sep 9, 2014 at 10:08 AM, Arthur Silva <arthurprs(at)gmail(dot)com> wrote:
>> > I'm continuously studying Postgres codebase. Hopefully I'll be able to
>> > make
>> > some contributions in the future.
>> >
>> > For now I'm intrigued about the extensive use of memory alignment. I'm
>> > sure
>> > there's some legacy and some architecture that requires it reasoning
>> > behind
>> > it.
>> >
>> > That aside, since it wastes space (a lot of space in some cases) there
>> > must
>> > be a tipping point somewhere. I'm sure one can prove aligned access is
>> > faster in a micro-benchmark but I'm not sure it's the case in a DBMS
>> > like
>> > postgres, specially in the page/rows area.
>> >
>> > Just for the sake of comparison Mysql COMPACT storage (default and
>> > recommended since 5.5) doesn't align data at all. Mysql NDB uses a fixed
>> > 4-byte alignment. Not sure about Oracle and others.
>> >
>> > Is it worth the extra space in newer architectures (specially Intel)?
>> > Do you guys think this is something worth looking at?
>>
>> Yes. At least in my opinion, though, it's not a good project for a
>> beginner. If you get your changes to take effect, you'll find that a
>> lot of things will break in places that are not easy to find or fix.
>> You're getting into really low-level areas of the system that get
>> touched infrequently and require a lot of expertise in how things work
>> today to adjust.
>
>
> I thought all memory alignment was (or at least the bulk of it) handled
> using some codebase wide macros/settings, otherwise how could different
> parts of the code inter-op? Poking this area might suffice for some initial
> testing to check if it's worth any more attention.
>
> Unaligned memory access received a lot attention in Intel post-Nehalen era.
> So it may very well pay off on Intel servers. You might find this blog post
> and it's comments/external-links interesting
> http://lemire.me/blog/archives/2012/05/31/data-alignment-for-speed-myth-or-reality/
>
> I'm a newbie in the codebase, so please let me know if I'm saying anything
> non-sense.

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. Even though intel handles
the vast majority of installations it's not gonna fly to optimize for
that platform at the expense of others so there'd have to be some kind
of compile time setting to control alignment behavior. That being
said, if you could pull this off cleanly, it'd be pretty neat.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-09-11 15:21:53 Re: bad estimation together with large work_mem generates terrible slow hash joins
Previous Message Petr Jelinek 2014-09-11 15:02:11 Re: Add shutdown_at_recovery_target option to recovery.conf