On Mon, Apr 23, 2018 at 12:34 PM, Konstantin Knizhnik
<k.knizhnik@postgrespro.ru> wrote:
> May be. But in any cases, there are several direction where compression can
> be used:
> - custom compression algorithms
> - libpq compression
> - page level compression
> ...
>
> and them should be somehow finally "married" with each other.
I agree that we should try to avoid multiplying the number of
compression-related APIs. Ideally there should be one API for
registering a compression algorithms, and then there can be different
methods of selecting that compression algorithm depending on the
purpose for which it will be used. For instance, you could select a
column compression format using some variant of ALTER TABLE ... ALTER
COLUMN, but you would obviously use some other method to select the
WAL compression format. However, it's a little unclear to me how we
would actually make the idea of a single API work. For column
compression, we need everything to be accessible through the catalogs.
For something like WAL compression, we need it to be completely
independent of the catalogs. Those things are opposites, so a single
API can't have both properties. Maybe there can be some pieces
shared, but as much as I'd like it to be otherwise, it doesn't seem
possible to share it completely.
I also agree with Ildus and Alexander that we cannot and should not
try to solve every problem in one patch. Rather, we should just think
ahead, so that we make as much of what goes into this patch reusable
in the future as we can.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
