Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
Date
Msg-id CAD21AoAabGPj3xMkSGtEsT3tgycVuku_Akhr8BDWByzgMe0SPQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Nov 14, 2017 at 6:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fabien COELHO <coelho@cri.ensmp.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.
>

Thank you for reviewing and committing the patch. I couldn't respond
promptly because slept but I agree with the changes.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] No mention of CREATE STATISTICS in event trigger docs
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted