Re: pgbench stats per script & other stuff - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pgbench stats per script & other stuff
Date
Msg-id CA+TgmoZEvNJ8wkVdHCsWnsz8Rz-MHebGp4DY+8WjiU-xYPT6Nw@mail.gmail.com
Whole thread Raw
In response to Re: pgbench stats per script & other stuff  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: pgbench stats per script & other stuff
List pgsql-hackers
On Thu, Jul 23, 2015 at 12:15 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>> 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 like "%" because this is about sharing, although this is not a
> percentage.

I liked @ because it makes sense to read it as the word "at".

>> I'd actually like to introduce a new pgbench option that selects a builtin
>> script by name, so that we can have more than three of them without running
>> out of option names (or going insane).  So suppose we introduce pgbench -b
>> BUILTIN_NAME, where BUILTIN_NAME is initially one of these:
>> classic, classic-simple-update, classic-select-only
>>
>> Then you can do pgbench -b classic@1 -b classic-select-only@9 or
>> similar to get 10% write, 90% read.
>
> I like this idea, as -b/-f would be symmetric. 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 actually inlined, even more
> code could be dropped from pgbench.

I think including classic would be a very good idea.  We might want to
add a TPC-C like workload in the future, or any number of other
things.  Naming things in a good way from the outset can only make
that easier.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: dinesh kumar
Date:
Subject: Re: Proposing COPY .. WITH PERMISSIVE
Next
From: Robert Haas
Date:
Subject: Re: Proposing COPY .. WITH PERMISSIVE