Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not all tables need even the capacity for 2^30 rows, much less 2^31, or 2^63. If you have a reference table with things like timezone information, color schemes, etc. and are using anything other than a SMALLINT (2^15), you're probably wasting space.

As to the maximal 8.6 GB mentioned, that's not nothing, _especially_ for RAM. Disk is cheap, but RAM isn't. If you have a smaller instance – say, an r6i.xlarge on AWS (4 vCPU, 32 GB RAM), that's 1/4 of the entire DB's memory.



so, what about my argument that PG has 23 bytes overhead per row and your space win is very small compared to that overhead?


It’s orthogonal, and also technically incorrect – the row overhead itself is indeed 23 bytes (less NULL bitmap), but it gets aligned to 24 bytes. Run pg_column_size(ROW()) if you’d like to check.

The fact that this overhead exists has nothing to do with the 8.6 GB of wasted space on the INTs.


> It’s orthogonal

I disagree its orthogonal and explained why. I guess lets agree on disagree.


Is that an innate property or a current implementation detail?


It’s the current implementation as of PG 8.2, I think. It’s [0] been there for a long time, in any case, and is unlikely to change in the near future.

[0]: https://www.postgresql.org/docs/current/storage-page-layout....


price for various features, like ACID.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: