Attached latest version of the patch.
Added slice decompression function to the compression handler.
Based on: 6b8548964bccd0f2e65c687d591b7345d5146bfa
Best regards,
Ildus Kurbangaliev
Best regards,
Ildus Kurbangaliev
On Tue, 2 Jul 2019 at 15:05, Ildus K <i.kurbangaliev@gmail.com> wrote:
>
> On Mon, 1 Jul 2019 at 17:28, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
>>
>> On Mon, Jul 1, 2019 at 5:51 PM Alvaro Herrera <alvherre@2ndquadrant.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
