| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Rod Taylor <rbt(at)zort(dot)ca>, Hackers List <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: NAMEDATALEN Changes |
| Date: | 2002-02-14 01:00:06 |
| Message-ID: | 4413.1013648406@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-02-14 01:07:48 | Re: geo_decls.h oopsie... |
| Previous Message | Tom Lane | 2002-02-14 00:44:41 | Re: When and where to check for function permissions |