Re: Improve compression speeds in pg_lzcompress.c

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Improve compression speeds in pg_lzcompress.c
Дата
Msg-id CAM-w4HPKtYVzG4Eb5YpM6mwgcx2fsVbM0oEKap-NmJdfzANjHw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improve compression speeds in pg_lzcompress.c  (John R Pierce <pierce@hogranch.com>)
Ответы Re: Improve compression speeds in pg_lzcompress.c  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Improve compression speeds in pg_lzcompress.c  ("ktm@rice.edu" <ktm@rice.edu>)
Re: Improve compression speeds in pg_lzcompress.c  (Takeshi Yamamuro <yamamuro.takeshi@lab.ntt.co.jp>)
Список pgsql-hackers
On Mon, Jan 7, 2013 at 10:21 AM, John R Pierce <pierce@hogranch.com> wrote:
> On 1/7/2013 2:05 AM, Andres Freund wrote:
>>
>> I think there should be enough bits available in the toast pointer to
>> indicate the type of compression. I seem to remember somebody even
>> posting a patch to that effect?
>> I agree that it's probably too late in the 9.3 cycle to start with this.
>
>
> so an upgraded database would have old toasted values in the old compression
> format, and new toasted values in the new format in an existing table?
> that's kind of ugly.

I haven't looked at the patch. It's not obvious to me from the
description that the output isn't backwards compatible. The way the LZ
toast compression works the output is self-describing. There are many
different outputs that would decompress to the same thing and the
compressing code can choose how hard to look for earlier matches and
when to just copy bytes wholesale but the decompression will work
regardless.


-- 
greg



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Extra XLOG in Checkpoint for StandbySnapshot
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"