Re: [PATCH] add long options to pgbench (submission 1)

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, fabriziomello(at)gmail(dot)com, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] add long options to pgbench (submission 1)
Date: 2013-06-25 19:09:39
Message-ID: alpine.DEB.2.02.1306252026070.27845@localhost6.localdomain6
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> I think I'd like to quibble with some of the names a bit, though.

That is a good idea, because I'm not a native English speaker and I was
not so sure for many options.

> The patch adds --fill-factor, but I think we should spell it
> without the hyphen: --fillfactor.

Fine with me.

> I think --quiet-log should be spelled --quiet.

ISTM that --quiet usually means "not verbose on stdout", so I added log
because this was specific to the log output, and that there may be a need
for a --quiet option for stdout at some time.

> I think --connect for each connection is not very descriptive; maybe
> --connection-per-transaction or something, although that's kind of long.

Yes, I think that it is too long. You have to type them!

What about '--reconnect'?

> I think -M should be aliased to --protocol, not --query-mode.

Fine with me.

> --skip-some-update is incorrectly pluralized; if that's
> what we're going to use, it should be --skip-some-updates.

Indeed.

> Alternatively, we could use --update-large-tables-only, which might
> make the intent more clear.

Yep, but quite long.

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

Indeed, it should.

Please find attached a v4 which takes into account most of your comments,
but "very very long" option names.

--
Fabien.

Attachment Content-Type Size
pgbench-longopts-v4.patch text/x-diff 14.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-06-25 19:15:13 Re: pluggable compression support
Previous Message Josh Berkus 2013-06-25 19:08:22 Re: pluggable compression support