Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization |
Дата | |
Msg-id | alpine.DEB.2.20.1708310903290.15830@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
|
Список | pgsql-hackers |
Hello Masahiko-san, > [...] Personally I prefer "t" for table creation because "c" for create > is a generic word. We might want to have another initialization command > that creates something. Ok, good point. About the patch: applies, compiles, works for me. A few minor comments. While re-reading the documentation, I think that it should be "Set custom initialization steps". It could be "Require ..." when -I implied -i, but since -i is still required the sentence does not seem to apply as such. "Destroying any existing tables: ..." -> "Destroy existing pgbench tables: ...". I would suggest to add short expanded explanations in the term definition, next to the triggering letter, to underline the mnemonic. Something like: c (cleanup) t (table creation) g (generate data) v (vacuum) p (primary key) f (foreign key) Also update the error message in checkCustomCommands to "ctgvpf". Cleanup should have a message when it is executed. I suggest "cleaning up...". Maybe add a comment in front of the array tables to say that the order is important, something like "tables in reverse foreign key dependencies order"? case 'I': ISTM that initialize_cmds is necessarily already allocated, thus I would not bother to test before pg_free. -- Fabien.
В списке pgsql-hackers по дате отправления: