Re: [PATCH] add --progress option to pgbench (submission 3)

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] add --progress option to pgbench (submission 3)
Date: 2013-06-22 20:51:48
Message-ID: alpine.DEB.2.02.1306222239330.1793@localhost6.localdomain6
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Mitsumasa,

Thanks for the review.

> * 2. Output format in result for more readable.
>> 5.0 s [thread 1]: tps = 1015.576032, AverageLatency(ms) = 0.000984663
>> 5.0 s [thread 0]: tps = 1032.580794, AverageLatency(ms) = 0.000968447
>> 10.0 s [thread 0]: tps = 1129.591189, AverageLatency(ms) = 0.000885276
>> 10.0 s [thread 1]: tps = 1126.267776, AverageLatency(ms) = 0.000887888
>
> However, interesting of output format(design) is different depending on the
> person:-). If you like other format, fix it.

I think that your suggestion is too verbose, and as far as automation is
oncerned I like "cut -f 2" unix filtering and other gnuplot processing...
but I see your point and it is a matter of taste. I'll try to propose
something in between, if I can.

> * 3. Thread name in output format is not nesessary.
> I cannot understand that thread name is displayed in each progress. I think
> that it does not need. I hope that output result sould be more simple also in
> a lot of thread. My images is here,
>
>> 5.0 s : tps = 2030.576032, AverageLatency(ms) = 0.000984663
>> 10.0 s : tps = 2250.591189, AverageLatency(ms) = 0.000885276
>
> This output format is more simple and intuitive. If you need result in each
> threads, please tell us the reason.

I agree that it would be better, but only a thread has access to its data,
if it must work with the "fork" pthread emulation, so each thread has to
do its report... If the "fork" emulation is removed and only real threads
are used, it would be much better, and one thread would be able to report
for everyone. The alternative is to do a feature which does not work with
fork emulation.

> * 4. Slipping the progress time.
> Whan I executed this patch in long time, I found slipping the progress time.
> This problem image is here.

Yep. I must change the test to align on the overall start time.

I'll submit a new patch later.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-06-22 21:08:46 Re: A better way than tweaking NTUP_PER_BUCKET
Previous Message Stephen Frost 2013-06-22 20:40:36 Re: A better way than tweaking NTUP_PER_BUCKET