Re: NAMEDATALEN Changes

On Wed, 2002-02-13 at 20:00, Tom Lane wrote:
> 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.

I've attached a pretty trivial patch that implements this. Instead of
automatically hashing NAMEDATALEN bytes, hashname() uses only strlen()
bytes: this should improve both the common case (small identifers, 5-10
characters long), as well as reduce the penalty when NAMEDATALEN is
increased. The patch passes the regression tests, FWIW. I didn't remove
cc_hashname() -- I'll tackle that tomorrow unless anyone objects...

I also did some pretty simple benchmarks; however, I'd appreciate it
anyone could confirm these results.

pg_bench: scale factor 1, 1 client, 10000 transactions.

hardware: p3-850, 384 MB RAM, slow laptop IDE disk

Run 1: Patch applied, NAMEDATALEN = 32

    number of transactions actually processed: 10000/10000
    tps = 19.940020(including connections establishing)
    tps = 19.940774(excluding connections establishing)

Run 2: Patch applied, NAMEDATALEN = 128

    number of transactions actually processed: 10000/10000
    tps = 20.849385(including connections establishing)
    tps = 20.850010(excluding connections establishing)

Run 3: Vanilla CVS, NAMEDATALEN = 32
(This is to check that the patch doesn't cause performance regressions
for the "common case")

    number of transactions actually processed: 10000/10000
    tps = 18.295418(including connections establishing)
    tps = 18.296191(excluding connections establishing)

The performance improvement @ NAMEDATALEN = 128 seems strange. As I
said, these benchmarks may not be particularly accurate, so I'd suggest
waiting for others to contribute results before drawing any conclusions.

Oh, and this is my first "real" Pg patch, so my apologies if I've
screwed something up. ;-)

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC