Re: checkpointer continuous flushing

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: checkpointer continuous flushing
Дата
Msg-id alpine.DEB.2.10.1603221053240.8198@sto
обсуждение исходный текст
Ответ на Re: checkpointer continuous flushing  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: checkpointer continuous flushing
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: checkpointer continuous flushing