Skip site navigation (1) Skip section navigation (2)

Re: Improve compression speeds in pg_lzcompress.c

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
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:48:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 7 January 2013 13:36, Greg Stark <stark(at)mit(dot)edu> 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.

Good point, and a great reason to use this patch rather than LZ4 for 9.3

We could even have tuning parameters for toast compression, as long as
we keep the on disk format identical.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: ktm@rice.eduDate: 2013-01-07 13:52:09
Subject: Re: Improve compression speeds in pg_lzcompress.c
Previous:From: Andres FreundDate: 2013-01-07 13:44:47
Subject: Re: Extra XLOG in Checkpoint for StandbySnapshot

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group