From: | Ildus Kurbangaliev <i(dot)kurbangaliev(at)gmail(dot)com> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [HACKERS] Custom compression methods |
Date: | 2019-07-08 12:00:21 |
Message-ID: | CAGRT6+NERrRZXpnTAqr+X6jF7ywRmt7nixD+ivp2g7_rGUaVsg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(dot)kurbangaliev(at)gmail(dot)com> wrote:
>
> 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
Attachment | Content-Type | Size |
---|---|---|
custom_compression_methods_v23.patch | text/x-patch | 346.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-07-08 12:17:41 | Re: [PATCH] Speedup truncates of relation forks |
Previous Message | Thomas Munro | 2019-07-08 11:56:08 | Re: Commitfest 2019-07, the first of five* for PostgreSQL 13 |