Re: [HACKERS] Custom compression methods

On Mon, 1 Jul 2019 at 17:28, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
wrote:

> On Mon, Jul 1, 2019 at 5:51 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
> wrote:
> > On 2019-Jul-01, Alexander Korotkov wrote:
> >
> > > As I get we're currently need to make high-level decision of whether
> > > we need this [1]. I was going to bring this topic up at last PGCon,
> > > but I didn't manage to attend. Does it worth bothering Ildus with
> > > continuous rebasing assuming we don't have this high-level decision
> > > yet?
> >
> > I agree that having to constantly rebase a patch that doesn't get acted
> > upon is a bit pointless. I see a bit of a process problem here: if the
> > patch doesn't apply, it gets punted out of commitfest and reviewers
> > don't look at it. This means the discussion goes unseen and no
> > decisions are made. My immediate suggestion is to rebase even if other
> > changes are needed.
>
> OK, let's do this assuming Ildus didn't give up yet :)
>

No, I still didn't give up :)
I'm going to post rebased version in few days. I found that are new
conflicts with
a slice decompression, not sure how to figure out them for now.

Also I was thinking maybe there is a point to add possibility to compress
any data
that goes to some column despite toast threshold size. In our company we
have
types that could benefit from compression even on smallest blocks.

Since pluggable storages were committed I think I should notice that
compression
methods also can be used by them and are not supposed to work only with
toast tables.
Basically it's just an interface to call compression functions which are
related with some column.

Best regards,
Ildus Kurbangaliev