From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:50:51 |
Message-ID: | 20130607155051.GN29964@alap2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-06-07 11:46:45 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-06-07 16:02:28 | Re: extensible external toast tuple support & snappy prototype |
Previous Message | Kevin Grittner | 2013-06-07 15:50:18 | Re: system catalog pg_rewrite column ev_attr document description problem |