Re: extensible external toast tuple support & snappy prototype - Mailing list pgsql-hackers

From Andres Freund
Subject Re: extensible external toast tuple support & snappy prototype
Date
Msg-id 20130607153821.GM29964@alap2.anarazel.de
Whole thread Raw
In response to Re: extensible external toast tuple support & snappy prototype  (Hannu Krosing <hannu@2ndQuadrant.com>)
Responses Re: extensible external toast tuple support & snappy prototype  (Hannu Krosing <hannu@2ndQuadrant.com>)
List pgsql-hackers
On 2013-06-07 17:27:28 +0200, Hannu Krosing wrote:
> On 06/07/2013 04:54 PM, Andres Freund wrote:
> >
> > I mean, we don't necessarily need to make it configurable if we just add
> > one canonical new "better" compression format. I am not sure that's
> > sufficient since I can see usecases for 'very fast but not too well
> > compressed' and 'very well compressed but slow', but I am personally not
> > really interested in the second case, so ...

> As DE-comression is often still fast for slow-but-good compression,
> the obvious use case for 2nd is read-mostly data

Well. Those algorithms still are up to magnitude or so slower
decompressing than something like snappy, lz4 or even pglz while the
compression ratio usually is only like 50-80% improved... So you really
need a good bit of compressible data (so the amount of storage actually
hurts) that you don't read all that often (since you then would
bottleneck on compression too often).
That's just not something I run across to regularly.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Cost limited statements RFC
Next
From: Tom Lane
Date:
Subject: Re: extensible external toast tuple support & snappy prototype