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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
Дата
Msg-id 1869.1510609841@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
Список pgsql-hackers
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.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Replication status in logical replication
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Fix number skipping in to_number