Re: Improve compression speeds in pg_lzcompress.c - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Improve compression speeds in pg_lzcompress.c
Date
Msg-id 20130107100524.GA5301@awork2.anarazel.de
Whole thread Raw
In response to Re: Improve compression speeds in pg_lzcompress.c  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Improve compression speeds in pg_lzcompress.c
List pgsql-hackers
On 2013-01-07 09:57:58 +0000, Simon Riggs wrote:
> On 7 January 2013 09:19, John R Pierce <pierce@hogranch.com> wrote:
> > On 1/7/2013 1:10 AM, Simon Riggs wrote:
> >>
> >> On 7 January 2013 07:29, Takeshi Yamamuro
> >> <yamamuro.takeshi@lab.ntt.co.jp>  wrote:
> >>
> >>> >Anyway, the compression speed in lz4 is very fast, so in my
> >>> >opinion, there is a room to improve the current implementation
> >>> >in pg_lzcompress.
> >>
> >> So why don't we use LZ4?
> >
> > what will changing compression formats do for compatability?
> >
> > this is for the compressed data in pg_toast storage or something? will this
> > break pg_upgrade style operations?
>
> Anything that changes on-disk format would need to consider how to do
> pg_upgrade. It's the major blocker in that area.
>
> For this, it would be possible to have a new format and old format
> coexist, but that will take more time to think through than we have
> for this release, so this is a nice idea for further investigation in
> 9.4. Thanks for raising that point.

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.

Greetings,

Andres Freund

--Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Improve compression speeds in pg_lzcompress.c
Next
From: John R Pierce
Date:
Subject: Re: Improve compression speeds in pg_lzcompress.c