Re: checkpointer continuous flushing

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: checkpointer continuous flushing
Date: 2016-03-22 10:00:51
Message-ID: alpine.DEB.2.10.1603221053240.8198@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2016-03-22 10:02:58 Re: checkpointer continuous flushing
Previous Message Andres Freund 2016-03-22 09:54:37 Re: checkpointer continuous flushing