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

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [PATCH] add --progress option to pgbench (submission 3)
Дата
Msg-id alpine.DEB.2.02.1306222239330.1793@localhost6.localdomain6
обсуждение исходный текст
Ответ на Re: [PATCH] add --progress option to pgbench (submission 3)  (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>)
Список 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.



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: A better way than tweaking NTUP_PER_BUCKET
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: A better way than tweaking NTUP_PER_BUCKET