On Thu, Sep 11, 2014 at 12:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Merlin Moncure <mmoncure@gmail.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.
