Re: pglz performance

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: pglz performance
Дата
Msg-id 20191101154828.GA15829@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: pglz performance  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: pglz performance  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: pglz performance  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
On 2019-Nov-01, Peter Eisentraut wrote:

> On 2019-10-25 07:05, Andrey Borodin wrote:
> > > 21 окт. 2019 г., в 14:09, Andrey Borodin <x4mmm@yandex-team.ru> написал(а):
> > > 
> > > With Silesian corpus pglz_decompress_hacked is actually decreasing performance on high-entropy data.
> > > Meanwhile pglz_decompress_hacked8 is still faster than usual pglz_decompress.
> > > In spite of this benchmarks, I think that pglz_decompress_hacked8 is safer option.
> > 
> > Here's v3 which takes into account recent benchmarks with Silesian Corpus and have better comments.
> 
> Your message from 21 October appears to say that this change makes the
> performance worse.  So I don't know how to proceed with this.

As I understand that report, in these results "less is better", so the
hacked8 variant shows better performance (33.8) than current (42.5).
The "hacked" variant shows worse performance (48.2) that the current
code.  The "in spite" phrase seems to have been a mistake.

I am surprised that there is so much variability in the performance
numbers, though, based on such small tweaks of the code.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: fe-utils - share query cancellation code
Следующее
От: Robert Haas
Дата:
Сообщение: Re: WIP/PoC for parallel backup