Tom Lane wrote:
> In the past we've rejected proposed patches for pgbench on the grounds
> that they would make results non-comparable to previous results. So the
> key question here is how much this affects the speed. Please be sure to
> test that on a 32-bit machine, not a 64-bit one.
>
Sheesh, who has a 32-bit machine anymore? I'll see what older hardware
I can dig up. I've realized there are two separate issues to be
concerned about:
1) On small scale data sets, what's the impact of the main piece of data
being shuffled around in memory (the account number in the accounts
table) now being 64 bits? That part might be significantly worse on
32-bit hardware.
2) How does the expansion in size of the related primary key on that
data impact the breakpoint where the database doesn't fit in RAM anymore?
I did just updated my pgbench-tools package this month so that it
happily runs against either 8.3 or 8.4/9.0 and I've done two rounds of
extensive test runs lately, so plenty of data to compare against here.
>> ! retval = (int64) strtol(res, &endptr, 19);
>>
>
> That bit is merely wishful thinking :-(
>
I did specificially say I didn't trust that call one bit.
There is a middle ground position here, similar to what Robert
suggested, that I just add a "large mode" to the program for people who
need it without touching the current case. That might allow me to
sidestep some of these issues I may not have a good answer to with
getting the \setshell feature working right in 64 bits, could just make
that one specific to "regular mode".
In any case, I think this limitation in what pgbench can do has risen to
be a full-on bug at this point for the expected users of the next
version, and I'll sit on this until there's something better we can make
available.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.com