Re: [HACKERS] Custom compression methods
От | Ildus Kurbangaliev |
---|---|
Тема | Re: [HACKERS] Custom compression methods |
Дата | |
Msg-id | CAGRT6+NERrRZXpnTAqr+X6jF7ywRmt7nixD+ivp2g7_rGUaVsg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Custom compression methods (Ildus K <i.kurbangaliev@gmail.com>) |
Ответы |
Re: [HACKERS] Custom compression methods
|
Список | 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.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
Вложения
В списке pgsql-hackers по дате отправления: