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

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
Date: 2017-11-14 00:41:58
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Tue, Nov 14, 2017 at 6:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

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


Masahiko Sawada
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-11-14 01:07:09 Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted
Previous Message David Rowley 2017-11-14 00:37:18 Re: [HACKERS] No mention of CREATE STATISTICS in event trigger docs