On Mon, Jun 19, 2017 at 12:19 PM, Robert Haas <robertmh...@gmail.com> wrote: > I don't have a specific use case in mind. However, datumCopy() is > sure to be a lot faster when typByVal is true, and see also the > documentation changes in commit > 8472bf7a73487b0535c95e299773b882f7523463.
Fair enough. I ask because at one time I informally benchmarked Postgres (using pgbench), where int4 (or maybe int8) primary keys were replaced with equivalent numeric primary keys. This was a SELECT benchmark. Anyway, the conclusion at the time was that it makes surprisingly little difference (I think it was ~5%), because cache misses dominate anyway, and the page layout doesn't really change (the fan-in didn't change *at all* either, at least for this one case, because of alignment considerations). I never published this result, because I didn't have time to test rigorously, and wasn't sure that there was sufficient interest. This was intended to confirm my intuition that cache misses were by far the main bottleneck (profiling also helped). I was thinking about putting abbreviated keys within internal B-Tree pages at the time (probably interleaved with the ItemIdData array). I've since realized that prefix compression is more or less prerequisite (to get value from a 1 or 2 byte abbreviated key), and that there are some painful issues with collations + text. You probably need to encode each internal page IndexTuple as a simple binary string that you always just memcmp() in a type/tuple descriptor agnostic fashion, leaving compression, truncation, and abbreviation as relatively trivial tasks. This is all very difficult, of course, which is why it wasn't seriously pursued. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
