| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Rahila Syed <rahilasyed(dot)90(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [REVIEW] Re: Compression of full-page-writes |
| Date: | 2014-09-11 17:04:43 |
| Message-ID: | CA+TgmoYbqs8Veyj6R-FaudWsZdmSR8V93c-bfnvEvUGS+35g-Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 11, 2014 at 12:58 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-09-11 12:55:21 -0400, Robert Haas wrote:
>> I advise supporting pglz only for the initial patch, and adding
>> support for the others later if it seems worthwhile. The approach
>> seems to work well enough with pglz that it's worth doing even if we
>> never add the other algorithms.
>
> That approach is fine with me. Note though that I am pretty strongly
> against adding support for more than one algorithm at the same time.
What if one algorithm compresses better and the other algorithm uses
less CPU time?
I don't see a compelling need for an option if we get a new algorithm
that strictly dominates what we've already got in all parameters, and
it may well be that, as respects pglz, that's achievable. But ISTM
that it need not be true in general.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Arthur Silva | 2014-09-11 17:12:09 | Re: Memory Alignment in Postgres |
| Previous Message | Tomas Vondra | 2014-09-11 16:59:09 | Re: Commitfest status |