Re: [HACKERS] usleep feature for pgbench

2007-07-07 Thread Peter Eisentraut
Jan Wieck wrote: You mean as a second, optional argument? Good idea. I think it should only be one argument, with the units being part of the variable value, if any. us = microseconds ms = milliseconds s = seconds (default) \sleep {value|:variable} [us|ms|s] -- Peter

Re: [HACKERS] usleep feature for pgbench

2007-07-07 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: Jan Wieck wrote: You mean as a second, optional argument? Good idea. I think it should only be one argument, with the units being part of the variable value, if any. No, because that makes it hard to do things like sleep for a small random number

Re: [HACKERS] usleep feature for pgbench

2007-07-07 Thread Jan Wieck
On 7/7/2007 11:40 AM, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Jan Wieck wrote: You mean as a second, optional argument? Good idea. I think it should only be one argument, with the units being part of the variable value, if any. No, because that makes it hard to do

Re: [HACKERS] usleep feature for pgbench

2007-07-06 Thread Greg Smith
On Thu, 5 Jul 2007, Jan Wieck wrote: Original pgbench reported 39, 37 and 33 TPS. Having my patch applied it reported 40, 38 and 33 TPS. Inserting a \usleep 1 after the update to accounts of a default equivalent script changed those numbers to 40, 37 and 33. I interpret that as does not

Re: [HACKERS] usleep feature for pgbench

2007-07-06 Thread Peter Eisentraut
Am Donnerstag, 5. Juli 2007 21:12 schrieb Jan Wieck: To test some changes in Slony I needed a \usleep [microseconds|:variable] in pgbench's scripting language to be able to have hundreds of concurrent running transactions without totally swamping the system. I was wondering if anyone

Re: [HACKERS] usleep feature for pgbench

2007-07-06 Thread Jan Wieck
On 7/6/2007 10:44 AM, Peter Eisentraut wrote: Am Donnerstag, 5. Juli 2007 21:12 schrieb Jan Wieck: To test some changes in Slony I needed a \usleep [microseconds|:variable] in pgbench's scripting language to be able to have hundreds of concurrent running transactions without totally

Re: [HACKERS] usleep feature for pgbench

2007-07-06 Thread Heikki Linnakangas
Jan Wieck wrote: On 7/6/2007 10:44 AM, Peter Eisentraut wrote: Am Donnerstag, 5. Juli 2007 21:12 schrieb Jan Wieck: To test some changes in Slony I needed a \usleep [microseconds|:variable] in pgbench's scripting language to be able to have hundreds of concurrent running transactions

Re: [HACKERS] usleep feature for pgbench

2007-07-06 Thread Jan Wieck
On 7/6/2007 1:32 PM, Heikki Linnakangas wrote: Jan Wieck wrote: On 7/6/2007 10:44 AM, Peter Eisentraut wrote: Am Donnerstag, 5. Juli 2007 21:12 schrieb Jan Wieck: To test some changes in Slony I needed a \usleep [microseconds|:variable] in pgbench's scripting language to be able to

Re: [HACKERS] usleep feature for pgbench

2007-07-06 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes: Jan Wieck wrote: You mean as a second, optional argument? Good idea. us = microseconds ms = milliseconds s = seconds (default) \sleep {value|:variable} [us|ms|s] Is that okay with everyone? I won't object, but is it really worth the

[HACKERS] usleep feature for pgbench

2007-07-05 Thread Jan Wieck
To test some changes in Slony I needed a \usleep [microseconds|:variable] in pgbench's scripting language to be able to have hundreds of concurrent running transactions without totally swamping the system. I was wondering if anyone would object to permanently adding this to the pgbench

Re: [HACKERS] usleep feature for pgbench

2007-07-05 Thread Tom Lane
Jan Wieck [EMAIL PROTECTED] writes: To test some changes in Slony I needed a \usleep [microseconds|:variable] in pgbench's scripting language to be able to have hundreds of concurrent running transactions without totally swamping the system. I was wondering if anyone would object to

Re: [HACKERS] usleep feature for pgbench

2007-07-05 Thread Jan Wieck
On 7/5/2007 3:34 PM, Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: To test some changes in Slony I needed a \usleep [microseconds|:variable] in pgbench's scripting language to be able to have hundreds of concurrent running transactions without totally swamping the system. I was

Re: [HACKERS] usleep feature for pgbench

2007-07-05 Thread Tom Lane
Jan Wieck [EMAIL PROTECTED] writes: I think I've coded it in a way that if one doesn't use the \usleep command at all, it will never even call gettimeofday() and use a NULL timeout in select() as it used to. Did you check that the observed performance for non-usleep-using scripts didn't

Re: [HACKERS] usleep feature for pgbench

2007-07-05 Thread Alvaro Herrera
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: I think I've coded it in a way that if one doesn't use the \usleep command at all, it will never even call gettimeofday() and use a NULL timeout in select() as it used to. Did you check that the observed performance for

Re: [HACKERS] usleep feature for pgbench

2007-07-05 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: Did you check that the observed performance for non-usleep-using scripts didn't change? If this extra overhead causes a reduction in reported TPS rates it would make it hard to compare older and newer tests. I keep wondering, why is

Re: [HACKERS] usleep feature for pgbench

2007-07-05 Thread Jan Wieck
On 7/5/2007 5:30 PM, Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: I think I've coded it in a way that if one doesn't use the \usleep command at all, it will never even call gettimeofday() and use a NULL timeout in select() as it used to. Did you check that the observed performance for