| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, 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-13 18:31:33 |
| Message-ID: | alpine.DEB.2.20.1711131925230.18461@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello Tom,
> Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-11-13 18:39:30 | Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization |
| Previous Message | Fabien COELHO | 2017-11-13 18:24:10 | Re: [HACKERS] pgbench regression test failure |