From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgbench is badly broken since July |
Date: | 2006-09-13 00:39:25 |
Message-ID: | 20060913.093925.63150272.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I have just realized that the recent patches in pgbench have altered its
> behavior in a way that destroys reproducibility of results --- I'm
> seeing reported TPS numbers about twice what they were before that.
> I'd love to say we did something in the past month that made the backend
> 2X faster, but sadly, tain't so :-(
>
> I've only done limited investigation but what seems to be happening
> is that the "-s" scale factor is no longer being applied to adjust the
> range of the random variables, leading to only part of the database
> being touched. For example, with -s = 10, the older code updates all 10
> "branches" rows but CVS HEAD only seems to touch bid = 1.
As far as I concern the bug is there, but in a different way what you
said. It seems "-s" works. Problem is, pgbench does not get the
default scaling factor (that is same as the number of rows in branches
table), instead alway uses the default scaling factor 1. I have fixed
the problem in CVS HEAD.
> I see that the code still thinks it is scaling the numbers, but the
> mechanism for doing that has changed drastically, and I suspect that's
> the problem. I assume there's some garden-variety bug in there.
>
> At a more fundamental level, the recent patches seem to mean that
> pg_dump is doing noticeably more work to issue its queries than it was
> before, and I wonder whether this isn't going to destroy cross-version
> reproducibility in its own way. Have you done any timing studies to
> verify that the new and old code have comparable performance? I don't
> mind enhancing pgbench's functionality for non-default tests, but I
> think it's important that the default case remain comparable over time.
> If there is a noticeable speed difference then I'd vote for going back
> to the klugy old code for adjusting the default script's values.
Let me do further performance testing.
> And at the nitpicking level, is ":tps" a good name for the variable that
> reflects the scaling factor? It seems awfully easy to confuse that with
> the TPS numbers that pgbench reports. Perhaps ":scale" or some such
> would be better.
I replaced all occurenes of "tps" to scale.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
From | Date | Subject | |
---|---|---|---|
Next Message | Carlo Florendo | 2006-09-13 00:52:14 | Re: Release notes |
Previous Message | Tom Lane | 2006-09-13 00:20:59 | Re: -HEAD planner issue wrt hash_joins on dbt3 ? |