But I see why this could be confusing. In the article he wrote:
> Postgres will happily add padding to the underlying data in order to make sure it is properly aligned at the physical layer. Having the data aligned ensures faster access time when retrieving pages from disk.
And this is correct. The problem is that "physical layer" refers to the physical memory layout and how things are loaded into the CPU. And not how they are stored in the disk(mostly).
I'm not expert in this subject, but as far I understand the main factor for this kind of behavior is the way a CPU reads data from its cache, i.e. 1 line(64bytes) at a time. And this is why we always pad to factors of 64(2, 4, 8, 16, 32).
This is the first time I read about this in the context of PG, but I've already encoutered the same issue in C and Go. So for me this is just a new manifestation of the same underlying problem.
None at all. The alignment is for cheap and easy access of data once it is in memory. It's probably rooted in PostgreSQL being written in C where aligned access is trivial, and dereference of an unaligned pointer is Undefined Behavior and requires more clunky code instead.
