Re: too much pgbench init output

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: too much pgbench init output
Дата
Msg-id 50E8EBC8.7030707@fuzzy.cz
обсуждение исходный текст
Ответ на Re: too much pgbench init output  (Tatsuo Ishii <ishii@postgresql.org>)
Ответы Re: too much pgbench init output  (Tatsuo Ishii <ishii@postgresql.org>)
Список pgsql-hackers
On 6.1.2013 03:03, Tatsuo Ishii wrote:
> As a committer, I have looked into the patch. I noticed two things:
>
> 1) In the help you put '-q' option into "Common options" section. I
> think this should be moved to "Initialization options" section because
> the option is only applied while initializing.

Good point, moved.

> 2) Shouldn't a long option for '-q' be provided? Something like
> '--quiet-progress-logging'?

I don't think so. Currently pgbench has either short or long option, not
both (for the same thing). I believe we should stick to this and either
choose "-q" or "--quiet-logging" but not both.

> 3) No patches for docs found (doc/src/sgml/pgbench.sgml)

I've added a brief description of the "-q" option into the docs. IMHO
it's enough but feel free to add some more details.


There's one more thing I've just noticed - the original version of the
patch simply removed the old logging, but this one keeps both old and
quiet logging. But the old logging still uses this:

    fprintf(stderr, "%d of %d tuples (%d%%) done.\n", ....

while the new logging does this

    fprintf(stderr, "%d of %d tuples (%d%%) done (elapsed %.2f s,
remaining %.2f s).\n",

i.e. it prints additional info about elapsed/estimated time. Do we want
to keep it this way (i.e. not to mess with the old logging) or do we
want to add these new fields to the old logging too?

I suggest to add it to the old logging, to keep the log messages the
same, the only difference being the logging frequency.


Tomas

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jon Nelson
Дата:
Сообщение: question: foreign key constraints and AccessExclusive locks
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: optimized DROP of multiple tables within a transaction