Horton

Re: [HACKERS] Custom compression methods

Ildus Kurbangaliev <i.kurbangaliev@gmail.com>

View thread View on postgr.es
From: Ildus Kurbangaliev <i.kurbangaliev@gmail.com>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Thomas Munro <thomas.munro@gmail.com>, David Steele <david@pgmasters.net>, Dmitry Dolgov <9erthalion6@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-07-08T12:00:21Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. docs: Update TOAST storage docs for configurable compression.

  2. Further tweaking of pg_dump's handling of default_toast_compression.

  3. Fix interaction of TOAST compression with expression indexes.

  4. Tidy up more loose ends related to configurable TOAST compression.

  5. Short-circuit slice requests that are for more than the object's size.

  6. Mostly-cosmetic adjustments of TOAST-related macros.

  7. Remove useless configure probe for <lz4/lz4.h>.

  8. Error on invalid TOAST compression in CREATE or ALTER TABLE.

  9. docs: Fix omissions related to configurable TOAST compression.

  10. More code cleanup for configurable TOAST compression.

  11. Bring configure support for LZ4 up to snuff.

  12. Make compression.sql regression test independent of default.

  13. Use valid compression method in brin_form_tuple

  14. Fix up pg_dump's handling of per-attribute compression options.

  15. Allow configurable LZ4 TOAST compression.

  16. Fix inconsistencies in the code

  17. Mostly-cosmetic improvements in memory chunk header alignment coding.

  18. Allow numeric to use a more compact, 2-byte header in many cases.