Re: extensible external toast tuple support & snappy prototype

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

In response to

Responses

Browse pgsql-hackers by date

  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