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.1711131925230.18461@lancre
Whole thread Raw
In response to Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello Tom,

> Masahiko Sawada <sawada.mshk@gmail.com> writes:
>> [ pgbench_custom_initialization_v16.patch ]
>
> I'm starting to review this patch, and I wonder how it is that you
> ended up with "c" as the command letter for dropping existing tables.
> Seems like "d" for DROP would be much less confusing.  I see that at
> one point "d" meant the data load step, but since you've gone with
> "g" for "generate data" that conflict is gone.

Indeed, you are right. As a reviewer, I can recall that there were some 
hesitations, not sure we ended up with the best possible choice.

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'm fine with anything consistent and easy to memorize, really.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] pgbench regression test failure
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization