Re: [PATCH] add long options to pgbench (submission 1) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] add long options to pgbench (submission 1)
Date
Msg-id CA+TgmoYFYT=fqDn=hL6b6kOYen5YfraPX0yA5SyPEAMuWgakDw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] add long options to pgbench (submission 1)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] add long options to pgbench (submission 1)  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Tue, Jun 25, 2013 at 12:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I would like to solicit opinions on whether this is a good idea.  I
>> understand that the patch author thinks it's a good idea, and I don't
>> have a strong position either way.  But I want to hear what other
>> people think.
>
> If it makes pgbench more consistent with psql's command line options,
> it seems reasonable to me.

OK, I think it does that.  So that's three votes in favor and none
opposed.  I think I'd like to quibble with some of the names a bit,
though.  The patch adds --fill-factor, but I think we should spell it
without the hyphen: --fillfactor.  I think --quiet-log should be
spelled --quiet.  I think --connect for each connection is not very
descriptive; maybe --connection-per-transaction or something, although
that's kind of long.  I think -M should be aliased to --protocol, not
--query-mode.  --skip-some-update is incorrectly pluralized; if that's
what we're going to use, it should be --skip-some-updates.
Alternatively, we could use --update-large-tables-only, which might
make the intent more clear.

On another note, it doesn't look like this updates the output of
pgbench --help, which seems important.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pluggable compression support
Next
From: Jeff Davis
Date:
Subject: Re: pg_filedump 9.3: checksums (and a few other fixes)