|From:||Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>|
|To:||Craig Ringer <craig(at)2ndquadrant(dot)com>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>|
|Subject:||Re: Custom compression methods|
|Views:||Raw Message | Whole Thread | Download mbox|
On Thu, 2 Nov 2017 23:02:34 +0800
Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 2 November 2017 at 17:41, Ildus Kurbangaliev
> <i(dot)kurbangaliev(at)postgrespro(dot)ru> wrote:
> > In this patch compression methods is suitable for MAIN and EXTENDED
> > storages like in current implementation in postgres. Just instead
> > only of LZ4 you can specify any other compression method.
> We've had this discussion before.
> Please read the "pluggable compression support" thread. See you in a
> few days ;) sorry, it's kinda long.
> IIRC there were some concerns about what happened with pg_upgrade,
> with consuming precious toast bits, and a few other things.
Thank you for the link, I didn't see that thread when I looked over
mailing lists. I read it briefly, and I can address few things
relating to my patch.
Most concerns have been related with legal issues.
Actually that was the reason I did not include any new compression
algorithms to my patch. Unlike that patch mine only provides syntax
and is just a way to give the users use their own compression algorithms
and deal with any legal issues themselves.
I use only one unused bit in header (there's still one free ;), that's
enough to determine that data is compressed or not.
I did found out that pg_upgrade doesn't work properly with my patch,
soon I will send fix for it.
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
|Next Message||Amit Kapila||2017-11-07 09:45:01||Re: parallelize queries containing initplans|
|Previous Message||Haribabu Kommi||2017-11-07 09:35:40||Re: Refactor handling of database attributes between pg_dump and pg_dumpall|