Re: [HACKERS][Proposal] LZ4 Compressed Storage Manager

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Николай Петров <nik(dot)petrov(dot)ua(at)yandex(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS][Proposal] LZ4 Compressed Storage Manager
Date: 2019-04-11 16:18:25
Message-ID: 20190411161825.ut44vjkh4zie6sgo@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 31, 2019 at 05:25:51PM +0300, Николай Петров wrote:
> Why it should be implemented on Storage Manager level instead of usage
> Pluggable storage API [9]?
> - From my perspective view Storage Manager level implementation
> allows to focus on proper I/O operations and compression.
> It allows to write much more simple realization. It's because of
> Pluggable storage API force you to implement more complex
> interfaces. To be honest, I am really hesitating about this point,
> especially because of Pluggable storage API allows to create
> extension without core code modification and it potentially allows
> to use more perfective compression algorithms (Table Access Manager
> allows you to get more information about storing data).
>
> I would like to implement a proof of concept
> and have a couple of questions:
> - your opinion about necessity of this feature
> (Compressed Storage Manager)
> - Is it good idea to implement DB compression on Storage Manager
> level? Perhaps it is better to use Pluggable storage API.
> - Is there any reason to refuse this proposal?
> - Are there any circumstances what didn't allow to implement
> Compressed Storage Manager?

Stepping back a bit, there are several levels of compression:

1. single field
2. across all fields in a row
3. across rows on a single page
4. across all rows in a table
5. across tables in a database

We currently do #1 with TOAST, and your approach would allow the first
three. #4 feels like it is getting near the features of columnar
storage. I think it is unclear if adding #2 and #3 produce enough of a
benefit to warrant special storage, given the complexity and overhead of
implementing it.

I do think the Pluggable storage API is the right approach, and, if you
are going to go that route, adding #4 compression seems very worthwhile.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2019-04-11 16:31:19 Re: [HACKERS][Proposal] LZ4 Compressed Storage Manager
Previous Message Peter Billen 2019-04-11 16:12:13 Re: serializable transaction: exclude constraint violation (backed by GIST index) instead of ssi conflict