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 20130607155051.GN29964@alap2.anarazel.de
Whole thread Raw
In response to Re: extensible external toast tuple support & snappy prototype  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: extensible external toast tuple support & snappy prototype
List pgsql-hackers
On 2013-06-07 11:46:45 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > 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 ...
> 
> IME, once we've changed it once, the odds that we'll want to change it
> again go up drastically.  I think if we're going to make a change here
> we should leave room for future revisions.

The above bit was just about how much control we give the user over the
compression algorithm used for compressing new data. If we just add one
method atm which we think is just about always better than pglz there's
not much need to provide the tunables already.

I don't think there's any question over the fact that we should leave
room on the storage level to reasonably easy add new compression
algorithms without requiring on-disk changes.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: system catalog pg_rewrite column ev_attr document description problem
Next
From: Alvaro Herrera
Date:
Subject: Re: extensible external toast tuple support & snappy prototype