From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: extensible external toast tuple support & snappy prototype |
Date: | 2013-06-07 15:38:21 |
Message-ID: | 20130607153821.GM29964@alap2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-06-07 15:46:45 | Re: extensible external toast tuple support & snappy prototype |
Previous Message | Greg Smith | 2013-06-07 15:35:18 | Re: Cost limited statements RFC |