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

From Fabien COELHO
Subject Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization
Date
Msg-id alpine.DEB.2.20.1708310903290.15830@lancre
Whole thread Raw
In response to Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Masahiko Sawada <sawada.mshk@gmail.com>)
List 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 by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] expanding inheritance in partition bound order