Re: Improve compression speeds in pg_lzcompress.c

From: "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: John R Pierce <pierce(at)hogranch(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Improve compression speeds in pg_lzcompress.c
Date: 2013-01-07 13:57:41
Message-ID: 20130107135741.GL14743@aart.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 07, 2013 at 01:36:33PM +0000, Greg Stark wrote:
> On Mon, Jan 7, 2013 at 10:21 AM, John R Pierce <pierce(at)hogranch(dot)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.
>

I think this comment refers to the lz4 option. I do agree that the patch
that was posted to improve the current compression speed should be able
to be implemented to allow the current results to be decompressed as well.

Regards,
Ken

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-01-07 14:03:21 Re: Improve compression speeds in pg_lzcompress.c
Previous Message ktm@rice.edu 2013-01-07 13:52:09 Re: Improve compression speeds in pg_lzcompress.c