Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization

Hello,

>> Hmmm. The existing "is_no_vacuum" variable is typed *both* as int (in
>> "main") and as bool (in "init"), called by main (yuk!). I see no reason to
>> choose the bad one for the global:-)
>
> Yeah, I think this might be a good timing to re-consider int-for-bool
> habits in pgbench. If we decided to change is_no_vacuum to bool I want
> to change other similar variables as well.

Franckly I would be fine with that, but committers might get touchy about 
"unrelated changes" in the patch... The "is_no_vacuum" is related to the 
patch and is already a bool -- if you chose the "init" definition as a 
reference -- so it is okay to bool it.

>> I think that the "-I" it should be added to the "--help" line, as it is done
>> with other short & long options.
>
> Okay, I'll leave it as of now. Maybe we can discuss later.

Maybe we did not understand one another. I'm just suggesting to insert
-I in the help line, that is change:
   "  --custom-initialize=[...]+\n"

to
   "  -I, --custom-initialize=[...]+\n"

I'm not sure it deserves to be discussed in depth later:-)

>> I wonder if this could be avoided easily? Maybe by setting the constraint
>> name explicitely so that the second one fails on the existing one, which is
>> fine, like for primary keys? [...]
>
> Good point, I agree with first option.

Ok.

>> Maybe the initial cleanup (DROP TABLE) could be made an option added to the
>> default, so that cleaning up the database could be achieved with some
>> "pgbench -i -I c", instead of connecting and droping the tables one by one
>> which I have done quite a few times... What do you think?
>
> Yeah, I sometimes wanted that. Having the cleaning up tables option
> would be good idea.

Ok.

> I'd say "g" for data generation would be better. Also, I'm inclined to
> add a command for the unlogged tables. How about this?
>
> c - [c]leanup / or [d]rop tables
> t - create table / [t]able creation or [c]reate table
> u - create unlogged table
> g - data generation / [g]enerate data
> p - [p]rimary key
> f - [f]oreign key
> v - [v]acuum

I'm okay with that. I also put an alternative with d/c above, without 
any preference from my part.

I'm not sure about "u", though. Unlogged, like tablespace, is an 
orthogonal option: other table creation options (I intend to submit one 
which conforms to the TPC-B standard, that is use an INT8 balance as INT4 
is not wide enough per spec, and always use an INT8 aid) may be also 
unlogged or tablespaced. So that would mean having two ways to trigger 
them... thus I would avoid it and keep only --unlogged.

-- 
Fabien.