From: | "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu> |
---|---|
To: | Arthur Silva <arthurprs(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 18:39:16 |
Message-ID: | 20140911183916.GM11672@aart.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 11, 2014 at 02:54:36PM -0300, Arthur Silva wrote:
> 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.
If the column order in the table was independent of the physical layout,
it would be possible to order columns to reduce the padding needed. Not
my suggestion, just repeating a valid comment from earlier in the thread.
Regards,
Ken
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-09-11 19:05:07 | Re: about half processes are blocked by btree, btree is bottleneck? |
Previous Message | Robert Haas | 2014-09-11 18:37:47 | Re: pg_background (and more parallelism infrastructure patches) |