Re: NAMEDATALEN Changes

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