On Mon, Apr 23, 2018 at 12:34 PM, Konstantin Knizhnik <k.knizh...@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
