Peter Eisentraut <peter_e@gmx.net> writes:
> That's around a 15% performance loss for increasing it to 64 or 128.
> Seems pretty scary actually.
Some of that could be bought back by fixing hashname() to not iterate
past the first \0 when calculating the hash of a NAME datum; and then
cc_hashname could go away. Not sure how much this would buy though.
Looking closely at Rod's script, I realize that the user+sys times it is
reporting are not the backend's but the pgbench client's. So it's
impossible to tell from this how much of the extra cost is extra I/O and
how much is CPU. I'm actually quite surprised that the client side
shows any CPU-time difference at all; I wouldn't think it ever sees any
null-padded NAME values.
regards, tom lane
