From: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
---|---|
To: | "Rod Taylor" <rbt(at)zort(dot)ca> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: namedatalen part 2 (cont'd) |
Date: | 2002-04-24 02:50:37 |
Message-ID: | 20020423225037.5a990707.nconway@klamath.dyndns.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 23 Apr 2002 23:36:14 -0300
"Rod Taylor" <rbt(at)zort(dot)ca> wrote:
> First is on pgbench -i (-s 5)
> Second is on pgbench -t 3000 -s 5
Haven't several people observed that the results from pgbench are
very inconsistent? Perhaps some results from OSDB would be worthwhile...
> The first test on a slow harddrive has a large effect for increasing the
> namedatalen length.
>
> Second through 4th sets don't really show any issues when the drives are
> quite a bit quicker -- IBM Deskstars stripped).
AFAICS, the only consistent results are the first set (on the slow
IDE drive) -- in which the performance degredation is quite high.
Based on that data, I'd vote against making any changes to NAMEDATALEN.
For the other data sets, performance is inconsistent. I'd be more inclined
to write that off as simply unreliable data and not necessarily an
indication that high NAMEDATALEN values don't have a performance impact
on that machine.
Cheers,
Neil
--
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-04-24 02:50:43 | Re: Index Scans become Seq Scans after VACUUM ANALYSE |
Previous Message | Bruce Momjian | 2002-04-24 02:48:44 | Re: RENAME TRIGGER patch (was [HACKERS] Odd(?) RI-trigger |