Re: Memory Alignment in Postgres - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Memory Alignment in Postgres
Date
Msg-id 20140909144531.GB16663@momjian.us
Whole thread Raw
In response to Memory Alignment in Postgres  (Arthur Silva <arthurprs@gmail.com>)
List pgsql-hackers
On Tue, Sep  9, 2014 at 11:08:05AM -0300, Arthur Silva 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?
> 
> I'm trying to messing with the *ALIGN macros but so far I wasn't able to get
> any conclusive results. My guess is that I'm missing something in the code or
> pg_bench doesn't stress the difference enough.

Postgres reads data block from disk and puts them in shared memory, then
the CPU accesses those values, like floats and integers, as though they
were in allocated memory, i.e. we make no adjustments to the data from
disk all the way to CPU.

I don't think anyone has measured the overhead of doing less alignment,
but I would be interested to see any test results produced.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: add modulo (%) operator to pgbench
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade and epoch