Re: too much pgbench init output - Mailing list pgsql-hackers

From Robert Haas
Subject Re: too much pgbench init output
Date
Msg-id CA+TgmoY+ppW3oAY8V00Kd8qypWPPdGj2a-Zj30A-Dxy-epc_Ug@mail.gmail.com
Whole thread Raw
In response to Re: too much pgbench init output  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: too much pgbench init output  (Tomas Vondra <tv@fuzzy.cz>)
List pgsql-hackers
On Tue, Oct 23, 2012 at 12:02 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Tomas Vondra wrote:
>
>> I've been thinking about this a bit more, and do propose to use an
>> option that determines "logging step" i.e. number of items (either
>> directly or as a percentage) between log lines.
>>
>> The attached patch defines a new option "--logging-step" that accepts
>> either integers or percents. For example if you want to print a line
>> each 1000 lines, you can to this
>>
>>   $ pgbench -i -s 1000 --logging-step 1000 testdb
>
> I find it hard to get excited about having to specify a command line
> argument to tweak this.  Would it work to have it emit messages
> depending on elapsed time and log scale of tuples emitted?  So for
> example emit the first message after 5 seconds or 100k tuples, then back
> off until (say) 15 seconds have lapsed and 1M tuples, etc?  The idea is
> to make it verbose enough to keep a human satisfied with what he sees,
> but not flood the terminal with pointless updates.  (I think printing
> the ETA might be nice as well, not sure).

I like this idea.  One of the times when the more verbose output is
really useful is when you expect it to run fast but then it turns out
that for some reason it runs really slow.  If you make the output too
terse, then you end up not really knowing what's going on.  Having it
give an update at least every 5 seconds would be a nice way to give
the user a heads-up if things aren't going as planned, without
cluttering the normal case.

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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: New statistics for WAL buffer dirty writes
Next
From: Robert Haas
Date:
Subject: Re: ToDo: KNN Search should to support DISTINCT clasuse?