Re: Optimize partial TOAST decompression

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: Optimize partial TOAST decompression
Дата
Msg-id E11354D1-6980-408D-AC4B-E147EB7CCDED@yandex-team.ru
обсуждение исходный текст
Ответ на Re: Optimize partial TOAST decompression  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: Optimize partial TOAST decompression  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers

> 30 сент. 2019 г., в 20:56, Tomas Vondra <tomas.vondra@2ndquadrant.com> написал(а):
>
> I mean this:
>
>   /*
>    * Use int64 to prevent overflow during calculation.
>    */
>   compressed_size = (int32) ((int64) rawsize * 9 + 8) / 8;
>
> I'm not very familiar with pglz internals, but I'm a bit puzzled by
> this. My first instinct was to compare it to this:
>
>   #define PGLZ_MAX_OUTPUT(_dlen)    ((_dlen) + 4)
>
> but clearly that's a very different (much simpler) formula. So why
> shouldn't pglz_maximum_compressed_size simply use this macro?

compressed_size accounts for possible increase of size during compression. pglz can consume up to 1 control byte for
each8 bytes of data in worst case. 
Even if whole data is compressed well - there can be prefix compressed extremely ineffectively. Thus, if you are going
todecompress rawsize bytes, you need at most compressed_size bytes of compressed input. 


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

Предыдущее
От: Soumyadeep Chakraborty
Дата:
Сообщение: Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch
Следующее
От: Ryan Lambert
Дата:
Сообщение: Re: FETCH FIRST clause PERCENT option