Re: checkpointer continuous flushing - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: checkpointer continuous flushing
Date
Msg-id alpine.DEB.2.10.1603221053240.8198@sto
Whole thread Raw
In response to Re: checkpointer continuous flushing  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
>> You took 5% of the tx on two 12 hours runs, totaling say 85M tx on
>> one and 100M tx on the other, so you get 4.25M tx from the first and
>> 5M from the second.
>
> OK
>
>> I'm saying that the percentile should be computed on the largest one
>> (5M), so that you get a curve like the following, with both curve
>> having the same transaction density on the y axis, so the second one
>> does not go up to the top, reflecting that in this case less
>> transactions where processed.
>
> Huh, that seems weird. That's not how percentiles or CDFs work, and I don't 
> quite understand what would that tell us.

It would tell us that for a given transaction number (in the 
latency-ordered list) whether its latency is above or below the other run.

I think it would probably show that the latency is always better for the 
patched version by getting rid of the crossing which has no meaning and 
seems to suggest, wrongly, that in some case the other is better than the 
first, but as the y axis of both curves are not in the same unit (not same 
transaction density) this is just an illusion implied by a misplaced 
normalization.

So I'm basically saying that the y axis should be just the transaction 
number, not a percent.

Anyway, these are just details, your figures show that the patch is a very 
significant win on SSDs, all is well!

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: checkpointer continuous flushing
Next
From: Fabien COELHO
Date:
Subject: Re: checkpointer continuous flushing