Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>>> Note that if "c" is freed by "d" (drop), then it may be worth considering
>>> that "t" (table) could be replaced by "c" (create).

>> I thought about that, but the argument that 'c' might mean different
>> sorts of create steps (e.g. create index) seemed reasonable. I think
>> we're best off leaving it as 't' in case of future expansion.

> Ok. Fine with me.

Committed that way, with some additional mostly-cosmetic changes:

* I did not much like the "--custom-initialize" option name, as that
conveys no information; arguably any option makes the initialization
"custom" in some way. Moreover it invites confusion with the use of
"custom" elsewhere in pgbench's docs for custom benchmarking scripts.
After some thought I chose "--init-steps", though if anyone has a better
idea I'm happy to listen. I would have gone with just "--steps", except
that the -s and -S short forms are both taken already. (Hm, maybe we
should use --steps and not have a short form?)

* I also tried to make the code use the "step" terminology consistently
internally, since it's already using "command" to refer to commands in
benchmarking scripts.

* I fixed it so that conflicts between the step-selecting options
are resolved after we've scanned all the options. The submitted
coding would do the wrong thing with, eg, --foreign-keys before -I.

* I changed the "drop" step to just drop all four tables in one
command; that way avoids having to make any assumption about what
foreign keys exist. (I suppose that constraints leading in different
directions aren't all that likely, but if we're trying to cater to
not-quite-default configurations, we might as well do this.)

* Minor other cosmetic cleanup.

regards, tom lane