Re: pgbench stats per script & other stuff - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench stats per script & other stuff
Date
Msg-id alpine.DEB.2.10.1512282309280.3689@sto
Whole thread Raw
In response to Re: pgbench stats per script & other stuff  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Hello Michaël,

>> And then I also had a look at src/port/snprintf.c, where things get
>> actually weird when no transactions are run for a script (emulated
>> with 2 scripts, one with @10000 and the second with @1):
>>  - 0 transactions (0.0% of total, tps = 0.000000)
>>  - latency average = -1.#IO ms
>>  - latency stddev = -1.#IO ms
>> And it seems that this is a bug in fmtfloat() because it does not
>> handle nan values correctly. Others, any thoughts about that?
>> It is possible to address things within your patch by using isnan()
>> and print another message but I think that we had better patch
>> snprintf.c if my analysis is right.
>
> FWIW, I just had a closer look at this portion and I arrived at the
> conclusion that sprintf implementation on Windows is just broken as it
> is not able to handle appropriately inf or nan as exceptions.
> fmtfloat@src/port/snprintf.c relies on the system's implementation of
> sprintf to handle those exceptions, however even directly calling
> sprintf results in the same weird output, inf showing up as "1.#IO"
> and nan as "-1.#IO". Anyone, feel free to disagree if I am missing
> something.

I have no opinion any about M$ implementation of double prettyprinting, 
but I agree that "-1.#IO" looks strange. WWW seems to say that "-1.INF" 
and "-1.IND" are the "normal" way for windows to say infinity or not a 
number. Well, if someone there thought it look good, I cannot help it.

> Still, it would be cool to have better error message when there is no
> value to show up to the user, like "no latency average" or "undefined
> latency average". That would be more elegant, and the patches proposed
> still lack that.

Hmmm. I do not buy that for several reasons:

For --progress style reporting you want NaN or whatever, because the 
output could be processed further unix-style from a pipe (grep/cut/...). 
This is also true for the final report. I would not want to change the 
output organisations for some special values, I would just like to get the 
value whatever it is, "NaN" or "Infinity" or even "-1.IND", so that the 
pipe commands would work.

Also, for the final report, it seems to me overkill to try to work around 
cases when pgbench does not run any transactions, which is basically not 
often, as the point is to run many transactions.

Finally this behavior already exists, the patch does not change anything 
AFAICS, and it is not its purpose.

So I would suggest to keep it that way.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: missing "SPI_finish" that isn't missing
Next
From: Boriss Mejias
Date:
Subject: Testing Postgresql 9.5 RC1 with Alfresco 5.0.d