Re: checkpointer continuous flushing - Mailing list pgsql-hackers

From Andres Freund
Subject Re: checkpointer continuous flushing
Date
Msg-id 20160322095302.GB3790@awork2.anarazel.de
Whole thread Raw
In response to Re: checkpointer continuous flushing  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: checkpointer continuous flushing  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On 2016-03-22 10:48:20 +0100, Tomas Vondra wrote:
> Hi,
> 
> On 03/22/2016 10:44 AM, Fabien COELHO wrote:
> >
> >
> >>>>1) regular-latency.png
> >>>
> >>>I'm wondering whether it would be clearer if the percentiles
> >>>where relative to the largest sample, not to itself, so that the
> >>>figures from the largest one would still be between 0 and 1, but
> >>>the other (unpatched) one would go between 0 and 0.85, that is
> >>>would be cut short proportionnaly to the actual performance.
> >>
> >>I'm not sure what you mean by 'relative to largest sample'?
> >
> >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.

My impression is that we actually know what we need to know anyway?



pgsql-hackers by date:

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