3 ms·
A little nitpick about > To those who still tend to use int4 in surrogate PKs, I have a question. Consider a table with 1 billion rows, with two columns – an i
by zigzag312 2y ago
A little nitpick about
> To those who still tend to use int4 in surrogate PKs, I have a question. Consider a table with 1 billion rows, with two columns – an integer and a timestamp. Will you see the difference in size between the two versions of the table
Wouldn't the important thing be an index size, not a table size? Table size already has 23-byte header + alignment padding. So 4 byte difference doesn't do much for table size. But fitting more of an index into memory could have some benefits. An index entry has 8-byte header.
Secondly, 1 billion rows (used in the example) are far too close to the maximum for int4 for comfort.
Great article nonetheless.
- srcreigh 2y agoYeah, there’s index size, and also disk size. Postgres packs table rows on disk tightly, but not in RAM. So I guess an 8kb page on disk could be more than 8kb in ram? Seems to only affect working memory for table row data. Still significant (especially in Postgres where rows are randomly ordered which is horrible for locality for range queries) but not a home run insight imo.