Thread: pgsql: pgbench: Allow changing weights for scripts

pgsql: pgbench: Allow changing weights for scripts

From
Alvaro Herrera
Date:
pgbench: Allow changing weights for scripts

Previously, all scripts had the same probability of being chosen when
multiple of them were specified via -b, -f, -N, -S.  With this commit,
-b and -f now search for an "@" in the script name and use the integer
found after it as the drawing probability for that script.

(One disadvantage is that if you have script whose names contain @, you
are now forced to specify "@1" at the end; otherwise the name's @ is
confused with a weight separator.  We don't expect many pgbench script
with @ in their names in the wild, so this shouldn't be too serious a
problem.)

While at it, rework the interface between addScript, process_file,
process_builtin, and findBuiltin.  It had gotten a bit out of hand with
recent commits.

Author: Fabien Coelho
Reviewed-By: Andres Freund, Robert Haas, Álvaro Herrera, Michaël Paquier
Discussion: http://www.postgresql.org/message-id/alpine.DEB.2.10.1603160721240.1666@sto

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/7bafffea647e21864cb857ab5b6fe266f2d0976a

Modified Files
--------------
doc/src/sgml/ref/pgbench.sgml |  25 +++--
src/bin/pgbench/pgbench.c     | 232 ++++++++++++++++++++++++++++--------------
2 files changed, 170 insertions(+), 87 deletions(-)


Re: pgsql: pgbench: Allow changing weights for scripts

From
Tom Lane
Date:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> pgbench: Allow changing weights for scripts

I'm seeing a bunch of warnings seemingly due to this commit:

pgbench.c: In function 'process_builtin':
pgbench.c:2765: warning: 'ps.stats.lag.sum2' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.lag.sum' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.lag.max' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.lag.min' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.lag.count' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.latency.sum2' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.latency.sum' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.latency.max' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.latency.min' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.latency.count' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.skipped' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.cnt' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.stats.start_time' is used uninitialized in this function
pgbench.c:2765: warning: 'ps.weight' is used uninitialized in this function

Usually, when gcc says that, it's not a false positive.

            regards, tom lane


Re: pgsql: pgbench: Allow changing weights for scripts

From
Alvaro Herrera
Date:
Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > pgbench: Allow changing weights for scripts
>
> I'm seeing a bunch of warnings seemingly due to this commit:
>
> pgbench.c: In function 'process_builtin':
> pgbench.c:2765: warning: 'ps.stats.lag.sum2' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.lag.sum' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.lag.max' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.lag.min' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.lag.count' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.latency.sum2' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.latency.sum' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.latency.max' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.latency.min' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.latency.count' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.skipped' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.cnt' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.stats.start_time' is used uninitialized in this function
> pgbench.c:2765: warning: 'ps.weight' is used uninitialized in this function
>
> Usually, when gcc says that, it's not a false positive.

I don't get any warnings here, but Jeff Janes had already reported
these.  I just pushed a fix.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Re: pgsql: pgbench: Allow changing weights for scripts

From
Fabien COELHO
Date:
> pgbench.c:2765: warning: 'ps.stats.lag.sum2' is used uninitialized in this function

Sorry for the noise.

Strangely, I did not get that warning with gcc 4.8.4.

ISTM that in stack variables are initialized to zero automatically, so
although it is not explicitely initialized, it is not uninitialized...

Moreover, these values are not actually "used" in the function, they are
just returned, and are to be initialized explicitely later on.

So gcc is wrong, but that does not mean that it should not be fixed.

Alvaro has just done that, which is overall a code improvement, so it is
for the better, and it shows that a wrong warning can lead to actual
benefits:-)

--
Fabien.


Re: pgsql: pgbench: Allow changing weights for scripts

From
Andres Freund
Date:
On 2016-03-19 20:23:03 +0100, Fabien COELHO wrote:
>
> >pgbench.c:2765: warning: 'ps.stats.lag.sum2' is used uninitialized in this function
>
> Sorry for the noise.
>
> Strangely, I did not get that warning with gcc 4.8.4.
>
> ISTM that in stack variables are initialized to zero automatically, so
> although it is not explicitely initialized, it is not uninitialized...

Uh? They're not.



Re: pgsql: pgbench: Allow changing weights for scripts

From
Fabien COELHO
Date:
>> ISTM that in stack variables are initialized to zero automatically, so
>> although it is not explicitely initialized, it is not uninitialized...
>
> Uh? They're not.

Indeed, I mixed up with "static", shame on me!

--
Fabien.