Re: [HACKERS] pgbench stats per script & other stuff

Indeed. The documentation is manually edited when submitting changes so as to minimize diffs, but then it does not correspond anymore to any actual output, so it is easy to do it wrong. Well, you fixed the "latency stddev" line to the sample output too, but in my trial run that line was not

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > > Hello, > > >>In doing this, I noticed that the latency output is wrong if you use -T > >>instead of -t; it always says the latency is zero because "duration" is > >>zero. I suppose it should be like in the attached instead. > > Indeed, I clearly overlooked option -t

Re: [HACKERS] pgbench stats per script & other stuff

Hello, In doing this, I noticed that the latency output is wrong if you use -T instead of -t; it always says the latency is zero because "duration" is zero. I suppose it should be like in the attached instead. Indeed, I clearly overlooked option -t (transactions) which I never use. Patch

Re: [HACKERS] pgbench stats per script & other stuff

Alvaro Herrera wrote: > In doing this, I noticed that the latency output is wrong if you use -T > instead of -t; it always says the latency is zero because "duration" is > zero. I suppose it should be like in the attached instead. At the same > time, it says "latency average: XYZ" instead of

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > > >- that it does work:-) I'm not sure what happens by the script selection > > process, it should be checked carefully because it was not designed > > with allowing a zero weight, and it may depend on its/their positions. > > It may already work, but it really needs

Re: [HACKERS] pgbench stats per script & other stuff

- that it does work:-) I'm not sure what happens by the script selection process, it should be checked carefully because it was not designed with allowing a zero weight, and it may depend on its/their positions. It may already work, but it really needs checking. Hmmm, it seems ok.

Re: [HACKERS] pgbench stats per script & other stuff

Hello Jeff, So I wanted to do something like: for f in `seq 0 5 100`; do pgbench -T 180 -c8 -j8 -b tpcb-like@$f -b select-only@100 done; But, I'm not allowed to specify a weight of zero. Indeed. I did not envision such a use case, but it is quite legitimate and interesting! I would hope

Re: [HACKERS] pgbench stats per script & other stuff

On Fri, Jul 17, 2015 at 6:50 AM, Fabien wrote: > > This patch adds per-script statistics & other improvements to pgbench > > Rationale: Josh asked for the per-script stats:-) > > Some restructuring is done so that all stats (-l --aggregate-interval > --progress

Re: [HACKERS] pgbench stats per script & other stuff

On Sat, Mar 19, 2016 at 11:34 AM, Alvaro Herrera wrote: > Jeff Janes wrote: >> On Sat, Mar 19, 2016 at 8:41 AM, Alvaro Herrera >> wrote: >> > I pushed your 25, with some additional minor tweaks. I hope I didn't >> > break anything; please

Re: [HACKERS] pgbench stats per script & other stuff

Jeff Janes wrote: > On Sat, Mar 19, 2016 at 8:41 AM, Alvaro Herrera > wrote: > > I pushed your 25, with some additional minor tweaks. I hope I didn't > > break anything; please test. > > I'm now getting compiler warnings: > > gcc version 4.4.7 20120313 (Red Hat

Re: [HACKERS] pgbench stats per script & other stuff

Hello Álvaro, I pushed your 25, with some additional minor tweaks. I hope I didn't break anything; please test. I've made a few tests and all looks well. I guess the build farm will say if it does not like it. Thanks, -- Fabien. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] pgbench stats per script & other stuff

I pushed your 25, with some additional minor tweaks. I hope I didn't break anything; please test. Fabien COELHO wrote: > >I don't "prefer" memory leaks -- I prefer interfaces that make sense. > > C is not designed to return two things, and if it is what is needed it looks > awkward whatever is

Re: [HACKERS] pgbench stats per script & other stuff

Hello Alvaro, If somebody specifies thousands of -f switches, they will waste a few bytes with each, but I'm hardly concerned about a few dozen kilobytes there ... Ok, so you prefer a memory leak. I hate it on principle. I don't "prefer" memory leaks -- I prefer interfaces that make sense.

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > >If somebody specifies thousands of -f switches, they will waste a few > >bytes with each, but I'm hardly concerned about a few dozen kilobytes > >there ... > > Ok, so you prefer a memory leak. I hate it on principle. I don't "prefer" memory leaks -- I prefer interfaces

Re: [HACKERS] pgbench stats per script & other stuff

On 3/4/16 1:53 PM, Fabien COELHO wrote: >>> That is why the "fs" variable in process_file is declared "static", >>> and why >>> I wrote "some hidden awkwarness". >>> >>> I did want to avoid a malloc because then who would free the struct? >>> addScript cannot to it systematically because builtins

Re: [HACKERS] pgbench stats per script & other stuff

That is why the "fs" variable in process_file is declared "static", and why I wrote "some hidden awkwarness". I did want to avoid a malloc because then who would free the struct? addScript cannot to it systematically because builtins are static. Or it would have to create an on purpose struct,

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > >However, this is still a bit broken -- you cannot return a stack > >variable from process_file, because the stack goes away once the > >function returns. You need to malloc it. > > That is why the "fs" variable in process_file is declared "static", and why > I wrote

Re: [HACKERS] pgbench stats per script & other stuff

*-21.patch does what you suggested above, some hidden awkwardness but much less that the previous one. Yeah, I think this is much nicer, don't you agree? Yep, I said "less awkwarness than previous", a pretty contrived way to say better:-) However, this is still a bit broken --

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: Hi, > *-21.patch does what you suggested above, some hidden awkwardness > but much less that the previous one. Yeah, I think this is much nicer, don't you agree? However, this is still a bit broken -- you cannot return a stack variable from process_file, because the

Re: [HACKERS] pgbench stats per script & other stuff

Hello Alvaro, I looked at 19.d and I think the design has gotten pretty convoluted. I think we could simplify with the following changes: struct script_t gets a new member, of type Command **, which is initially null. function process_builtin receives the complete script_t (not individual

Re: [HACKERS] pgbench stats per script & other stuff

Michael Paquier wrote: > On Tue, Feb 9, 2016 at 4:22 AM, Fabien COELHO wrote: > > Hmmm, I type them and I'm not so good with a keyboard, so "se" is better > > than: > > > > "selct-onlyect-only". > > I can understand that feeling. Pushed 19-e, thanks. -- Álvaro Herrera

Re: [HACKERS] pgbench stats per script & other stuff

I looked at 19.d and I think the design has gotten pretty convoluted. I think we could simplify with the following changes: struct script_t gets a new member, of type Command **, which is initially null. function process_builtin receives the complete script_t (not individual memebers of it)

Re: [HACKERS] pgbench stats per script & other stuff

On Tue, Feb 9, 2016 at 4:22 AM, Fabien COELHO wrote: >> + /* compute total_weight */ >> + for (i = 0; i < num_scripts; i++) >> + { >> + total_weight += sql_script[i].weight; >> + >> + /* detect overflow... */ >> If let as int64,

Re: [HACKERS] pgbench stats per script & other stuff

Hi Michaël, Attached 19-d and 19-e. +/* return builtin script "name", or fail if not found */ builtin does not sound like correct English to me, but built-in is. I notice that "man bash" uses "builtin" extensively, so I think it is okay like that, but I would be fine as well with

Re: [HACKERS] pgbench stats per script & other stuff

On Fri, Feb 5, 2016 at 12:53 AM, Fabien COELHO wrote: >> Something is wrong with patch d. I noticed two things, >> 1. the total_weight stuff can overflow, > > It can generate an error on overflow by checking the total_weight while it > is being computed. I've switched

Re: [HACKERS] pgbench stats per script & other stuff

Hello Michaël, + /* compute total_weight */ + for (i = 0; i < num_scripts; i++) + { + total_weight += sql_script[i].weight; + + /* detect overflow... */ If let as int64, you may want to remove this overflow check, or keep it as int32. I'd rather

Re: [HACKERS] pgbench stats per script & other stuff

I closed this one as "committed", since we pushed a bunch of parts. Please submit the two remaining ones to the next commitfest. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing

Re: [HACKERS] pgbench stats per script & other stuff

Hello Alvaro, Something is wrong with patch d. I noticed two things, 1. the total_weight stuff can overflow, It can generate an error on overflow by checking the total_weight while it is being computed. I've switched total_weight to int64 so it is now really impossible to overflow with

Re: [HACKERS] pgbench stats per script & other stuff

Hello Michaël, Two rebase attached. - 15-e: prefix selection for -b - if (strncmp(builtin_script[i].name, name, - strlen(builtin_script[i].name)) == 0) + if (strncmp(builtin_script[i].name, name, len) == 0) I agree with

Re: [HACKERS] pgbench stats per script & other stuff

On Fri, Jan 29, 2016 at 11:28 PM, Fabien COELHO wrote: > Here is a rebase of the 3 remaining parts: > - 15-c: per script stats > - 15-d: weighted scripts > - 15-e: prefix selection for -b Regarding patch d. + /* compute total_weight */ + for (i = 0; i <

Re: [HACKERS] pgbench stats per script & other stuff

Hello Alvaro, Thanks for the progress! I pushed this, along with a few more tweaks, mostly adding comments and moving functions so that related things are together. I hope I didn't break anything. Looks ok. Here is a rebase of the 3 remaining parts: - 15-c: per script stats - 15-d:

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > The answer is essentially yes, the field is needed for the "aggregated" mode > where this specific behavior is used. OK, thanks, that looks better to me. Can you now appreciate why I asked for split patches? If I had to go over the big patch I probably wouldn't have been

Re: [HACKERS] pgbench stats per script & other stuff

Hello again, Obviously this would work. I did not think the special case was worth the extra argument. This one has some oddity too, because the second argument is ignored depending on the third. Do as you feel. Actually my question was whether keeping the original start_time was the

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > >It seems a bit funny to have the start_time not be reset when 0.0 is > >passed, which is almost all the callers. Using a float as a boolean > >looks pretty odd; is that kosher? Maybe it'd be a good idea to have a > >separate boolean flag instead? > Obviously this would

Re: [HACKERS] pgbench stats per script & other stuff

Hello again, Here's part b rebased, pgindented and with some minor additional tweaks (mostly function commands and the function renames I mentioned). Patch looks ok to me, various tests where ok as well. Still concerned about the unlocked stat accums. See my arguments in other mail. I

Re: [HACKERS] pgbench stats per script & other stuff

Hello again, If you want to implement real non-ambiguous-prefix code (i.e. have "se" for "select-only", but reject "s" as ambiguous) be my guest. I'm fine with filtering out ambiguous cases (i.e. just the "s" case). Attached a small patch for that. -- Fabien.diff --git

Re: [HACKERS] pgbench stats per script & other stuff

Hello Alvaro, I'm not really sure about the fact that we operate on those Stats structs without locking. I see upthread you convinced Michael that it was okay, but is it really? How severe is the damage if two threads happen to collide? For stats shared among threads, when it occurs one

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > You know how delighted I am to split patches... Yes, of course, it's the most interesting task in the world. I'm fully aware of that. FWIW I'm going to apply a preliminary commit to pgindent-clean the file before your patches, then apply each patch as pgindent-clean.

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > a) add -b option for cumulating builtins and rework internal script >management so that builtin and external scripts are managed the >same way. I tweaked this a bit. I found a bug in threadRun: it was reading the commands first, and setting st->use_file later.

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > a) add -b option for cumulating builtins and rework internal script >management so that builtin and external scripts are managed the >same way. I'm uncomfortable with the prefix-matching aspect of -b. It makes "-b s" ambiguous -- whether it stands for select-only

Re: [HACKERS] pgbench stats per script & other stuff

Hello Alvaro, I'm looking at this part of your patch and I think it's far too big to be a simple refactoring. Would you split it up please? You know how delighted I am to split patches... Here is a 5 part ordered patch serie: a) add -b option for cumulating builtins and rework internal

Re: [HACKERS] pgbench stats per script & other stuff

Hello Alvaro, Here is a two part v12, which: part a (refactoring of scripts and their stats): - fix option checks (-i alone) - s/repleacable/replaceable/ in doc - keep small description in doc and help for -S & -N - fix 2 comments for pg style - show builtin list if not found I'm

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > > Here is a two part v12, which: > > part a (refactoring of scripts and their stats): > - fix option checks (-i alone) > - s/repleacable/replaceable/ in doc > - keep small description in doc and help for -S & -N > - fix 2 comments for pg style > - show builtin list if

Re: [HACKERS] pgbench stats per script & other stuff

Hello Michaël, And then I also had a look at src/port/snprintf.c, where things get actually weird when no transactions are run for a script (emulated with 2 scripts, one with @1 and the second with @1): - 0 transactions (0.0% of total, tps = 0.00) - latency average = -1.#IO ms -

Re: [HACKERS] pgbench stats per script & other stuff

On Wed, Dec 16, 2015 at 4:09 PM, Michael Paquier wrote: > Yeah, that's actually fine. I just had a look at Windows stuff, and > things seem to be correct on this side for double: > https://msdn.microsoft.com/en-us/library/aa691373%28v=vs.71%29.aspx > And then I also had

Re: [HACKERS] pgbench stats per script & other stuff

Here is a two part v12, which: part a (refactoring of scripts and their stats): - fix option checks (-i alone) - s/repleacable/replaceable/ in doc - keep small description in doc and help for -S & -N - fix 2 comments for pg style - show builtin list if not found part b (weight) - check

Re: [HACKERS] pgbench stats per script & other stuff

It seems also that it would be a good idea to split the patch into two parts: 1) Refactor the code so as the existing test scripts are put under the same umbrella with addScript, adding at the same time the new option -b. 2) Add the weight facility and its related statistics. Sigh. The patch

Re: [HACKERS] pgbench stats per script & other stuff

"sum" is a double so count is converted to 0.0, 0.0/0.0 == NaN, hence the comment. PG code usually avoids that, and I recall static analyze tools type coverity complaining that this may lead to undefined behavior. While I agree that this would lead to NaN... Hmmm. In this case that is what

Re: [HACKERS] pgbench stats per script & other stuff

On Tue, Dec 15, 2015 at 8:41 PM, Fabien COELHO wrote: >> PG code usually avoids that, and I recall static analyze tools type >> coverity complaining that this may lead to undefined behavior. While I >> agree that this would lead to NaN... > > > Hmmm. In this case that is what

Re: [HACKERS] pgbench stats per script & other stuff

On Tue, Dec 15, 2015 at 5:53 AM, Fabien COELHO wrote: > I wrote: >> Why would the likelyhood of an issue be small here? > > The time to update one stat (<< 100 cycles ?) to the time to do a > transaction with the database (typically Y ms), so the likelyhood of two > thread to

Re: [HACKERS] pgbench stats per script & other stuff

-Do not update pgbench_tellers and -pgbench_branches. -This will avoid update contention on these tables, but -it makes the test case even less like TPC-B. +Shorthand for -b simple-update@1. I don't think it is a good idea to remove entirely the

Re: [HACKERS] pgbench stats per script & other stuff

On Sat, Oct 3, 2015 at 3:11 PM, Fabien COELHO wrote: > >> Here is a v10, which is a rebase because of the "--progress-timestamp" >> option addition. > > > Here is a v11, which is a rebase after some recent changes committed to > pgbench. +The provided scriptname

Re: [HACKERS] pgbench stats per script & other stuff

Here is a v10, which is a rebase because of the "--progress-timestamp" option addition. Here is a v11, which is a rebase after some recent changes committed to pgbench. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 0ac40f1..e3a90e5 100644 ---

Re: [HACKERS] pgbench stats per script & other stuff

On Sat, Sep 26, 2015 at 3:27 AM, Fabien COELHO wrote: > Here is a v10, which is a rebase because of the "--progress-timestamp" > option addition. I do not see it attached. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent

Re: [HACKERS] pgbench stats per script & other stuff

Here is a v10, which is a rebase because of the "--progress-timestamp" option addition. I do not see it attached. Indeed. Here it is. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 0ac40f1..e3a90e5 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++

Re: [HACKERS] pgbench stats per script & other stuff

Here is a v10, which is a rebase because of the "--progress-timestamp" option addition. It also include the fix for the tps without connection computation and some minor code simplification, so it is redundant with this bug fix patch: https://commitfest.postgresql.org/7/378/ --

Re: [HACKERS] pgbench stats per script & other stuff

On Thu, Sep 3, 2015 at 3:26 AM, Fabien COELHO wrote: > I've left out: > - removing -N/-S upward compatibility shorthands >but I will not cry if they are removed I see no particular merit to breaking backward compatibility here. -- Robert Haas EnterpriseDB:

Re: [HACKERS] pgbench stats per script & other stuff

I've left out: - removing -N/-S upward compatibility shorthands but I will not cry if they are removed I see no particular merit to breaking backward compatibility here. I agree, but I would not fight for this. I think there is a good argument *NOT* to add more if new builtin scripts

Re: [HACKERS] pgbench stats per script & other stuff

On 2015-09-02 20:20:45 +0200, Fabien COELHO wrote: > >>+static SQLScript sql_script[MAX_SCRIPTS]; > >> > >>+static struct { > >>+ char *name; /* very short name for -b ...*/ > >>+ char *desc; /* short description */ > >>+ char *script; /* actual pgbench script */ > >>+} builtin_script[]

Re: [HACKERS] pgbench stats per script & other stuff

Hello Anders, This v9 : - add "-b list" to show the list of builtins - remove the explicit --per-scripts-stats option, which is instead automatically set when several scripts are run or with per-command latencies (-r) - count scripts from 1 instead of 0 in the output I've left out: -

Re: [HACKERS] pgbench stats per script & other stuff

Right now builtins and user defined scripts are stored in different data structures. I'd rather see them in the same. They already are in the same array (sql_script) when pre-processed and executed, there is no distinction beyond initialization. The builtin_script array contains the

Re: [HACKERS] pgbench stats per script & other stuff

On 2015-07-30 18:03:56 +0200, Fabien COELHO wrote: > > >v6 is just a rebase after a bug fix by Andres Freund. > > > >Also a small question: The patch currently displays pgbench scripts > >starting numbering at 0. Probably a little too geek... should start at 1? > > v7 is a rebase after another

Re: [HACKERS] pgbench stats per script & other stuff

On Wed, Sep 2, 2015 at 5:55 PM, Andres Freund wrote: > On 2015-09-02 14:36:51 -0400, Robert Haas wrote: >> On Wed, Sep 2, 2015 at 2:20 PM, Fabien COELHO wrote: >> >> I'm wondering if percentages instead of weights would be a better >> >> idea. That'd mean

Re: [HACKERS] pgbench stats per script & other stuff

Hello Andres, Maybe add --builtin list to show them? Yep, easy enough. [...] +Shorthand for -b simple-update@1. +Shorthand for -b select-only@1. I'm a bit inclined to remove these options. Hm... This is really backward compatibility, and people may find reference to

Re: [HACKERS] pgbench stats per script & other stuff

On Wed, Sep 2, 2015 at 2:20 PM, Fabien COELHO wrote: >> I'm wondering if percentages instead of weights would be a better >> idea. That'd mean you'd be forced to be more careful when adding another >> script (having to adjust the percentages of other scripts) but arguably >>

Re: [HACKERS] pgbench stats per script & other stuff

On 2015-09-02 14:36:51 -0400, Robert Haas wrote: > On Wed, Sep 2, 2015 at 2:20 PM, Fabien COELHO wrote: > >> I'm wondering if percentages instead of weights would be a better > >> idea. That'd mean you'd be forced to be more careful when adding another > >> script (having to

Re: [HACKERS] pgbench stats per script other stuff

v7 is a rebase after another small bug fix in pgbench. v8 is a rebase after yet another small bug fix in pgbench. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 2517a3a..99670d4 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++

Re: [HACKERS] pgbench stats per script other stuff

v6 is just a rebase after a bug fix by Andres Freund. Also a small question: The patch currently displays pgbench scripts starting numbering at 0. Probably a little too geek... should start at 1? v7 is a rebase after another small bug fix in pgbench. -- Fabien.diff --git

Re: [HACKERS] pgbench stats per script other stuff

v6 is just a rebase after a bug fix by Andres Freund. Also a small question: The patch currently displays pgbench scripts starting numbering at 0. Probably a little too geek... should start at 1? -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index

Re: [HACKERS] pgbench stats per script other stuff

I liked @ because it makes sense to read it as the word at. Yep, why not. Prepending classic to the names does not look necessary. I would suggest tpcb-like, simple-update select-only, or even maybe any prefix. If the bench scripts could be read from some pg directory instead of being

Re: [HACKERS] pgbench stats per script other stuff

Also, maybe per-command detailed stats should use the same common struct to hold data as all other stats. I did not change it because it is maintained in a different part of the code. I played just once with the --report-latencies option and was astonished that meta commands showed negative

Re: [HACKERS] pgbench stats per script other stuff

On Wed, Jul 22, 2015 at 1:54 PM, Josh Berkus j...@agliodbs.com wrote: If so, I would vote for: -f script1.bench:3 -f script2.bench:1 over: -f script1.bench -w 3 -f script2.bench -w 1 Making command-line options order-dependant breaks a lot of system call libraries in various languages,

Re: [HACKERS] pgbench stats per script other stuff

Yes, I think that's a good idea. I don't know whether : is the right separator; I kind of line @. But that's bikeshedding. Possible ASCII contenders should avoid shell and filename interaction, which exclude * ? ! / [ ] . - $ and so on: those that seem to remain are @ , = : % # +. I

Re: [HACKERS] pgbench stats per script other stuff

Fabien COELHO wrote: [...] and that a subsequent -w modifies the meaning of the script-specifiying argument already read. That strikes me as a very unintuitive interface. Ok, I understand this afterward modification objection. What if the -w would be required *before*, and supply a

Re: [HACKERS] pgbench stats per script other stuff

On 07/21/2015 10:25 PM, Fabien COELHO wrote: Hello Josh, Maybe -f file.sql:weight (yuk from my point of view, but it can be done easily). Maybe it's past time for pgbench to have a config file? That is an idea. For simple usage, for backward compatibility and for people like me who

Re: [HACKERS] pgbench stats per script other stuff

If so, I would vote for: -f script1.bench:3 -f script2.bench:1 over: -f script1.bench -w 3 -f script2.bench -w 1 Ok, I'll take that into consideration. Any other opinion out there? The current v3 version is: -w 3 -f script1.bench -w 1 -f script2.bench With provision to generate

Re: [HACKERS] pgbench stats per script other stuff

On 2015-07-22 10:54:14 -0700, Josh Berkus wrote: Making command-line options order-dependant breaks a lot of system call libraries in various languages, as well as being easy to mess up. What? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] pgbench stats per script other stuff

On Tue, Jul 21, 2015 at 10:42 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: sh ./pgbench -T 3 -B -N -w 2 -S -w 7 --per-script-stats That is a truly horrifying abuse of command-line arguments. -1 from me, or minus more than one if I've got that many chits to burn. Are you against the -w, or

Re: [HACKERS] pgbench stats per script other stuff

5~5~5~ That is a truly horrifying abuse of command-line arguments. -1 from me, or minus more than one if I've got that many chits to burn. Are you against the -w, or against saying that pgbench execute scripts, whether internal or from files? I'm against the idea that we accept multiple

Re: [HACKERS] pgbench stats per script other stuff

Hello Robert, Pgbench *currently* already accept multiple -f ... options, and this is a good thing to test realistic loads which may intermix several kind of transactions, say a lot of readonly and some update or insert, and very rare deletes... Hmm, I didn't realize that. The code looks a

Re: [HACKERS] pgbench stats per script other stuff

[...] and that a subsequent -w modifies the meaning of the script-specifiying argument already read. That strikes me as a very unintuitive interface. Ok, I understand this afterward modification objection. What if the -w would be required *before*, and supply a weight for (the first/maybe

Re: [HACKERS] pgbench stats per script other stuff

On Tue, Jul 21, 2015 at 12:29 PM, Fabien COELHO coe...@cri.ensmp.fr wrote: Pgbench *currently* already accept multiple -f ... options, and this is a good thing to test realistic loads which may intermix several kind of transactions, say a lot of readonly and some update or insert, and very rare

Re: [HACKERS] pgbench stats per script other stuff

On 07/21/2015 09:29 AM, Fabien COELHO wrote: Maybe -f file.sql:weight (yuk from my point of view, but it can be done easily). Maybe it's past time for pgbench to have a config file? Given that we want to define some per-workload options, the config file would probably need to be YAML or JSON,

Re: [HACKERS] pgbench stats per script other stuff

On Fri, Jul 17, 2015 at 9:50 AM, Fabien coe...@cri.ensmp.fr wrote: sh ./pgbench -T 3 -B -N -w 2 -S -w 7 --per-script-stats That is a truly horrifying abuse of command-line arguments. -1 from me, or minus more than one if I've got that many chits to burn. I have been thinking that the way to

Re: [HACKERS] pgbench stats per script other stuff

Hello Robert, On Fri, Jul 17, 2015 at 9:50 AM, Fabien coe...@cri.ensmp.fr wrote: sh ./pgbench -T 3 -B -N -w 2 -S -w 7 --per-script-stats That is a truly horrifying abuse of command-line arguments. -1 from me, or minus more than one if I've got that many chits to burn. Are you against

Re: [HACKERS] pgbench stats per script other stuff

Oops, as usual I forgot something... This v2 removes old stats code that was put in comment and simplify the logic when counting lag times, as they are now taken into account at the end of the transaction instead of at the beginning. This patch adds per-script statistics other