On Mon, Jun 19, 2017 at 12:19 PM, Robert Haas <robertmhaas@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