Re: QuickLZ compression algorithm (Re: Inclusion in the PostgreSQL backend for toasting rows)

Holger Hoffstaette wrote:
> On Mon, 05 Jan 2009 13:44:57 -0500, Andrew Chernow wrote:
>
>> Robert Haas wrote:
>>> What we do have is a suggestion from several people that the database
>>> shouldn't be in the business of compressing data AT ALL. If we want
>
> DB2 users generally seem very happy with the built-in compression.
>
>> IMHO, this is a job for the application.
>
> Changing applications is several times more expensive and often simply not
> possible.
>
>

The database can still handle all of the compression requirements if the
"application" creates a couple user-defined functions (probably in c)
that utilize one of the many existing compression libraries (hand picked
for their needs). You can use them in triggers to make it transparent.
You can use them directly in statements. You can control selecting
the data compressed or uncomrpessed, which is a valid use case for
remote clients that have to download a large bytea or text. You can
toggle compression algorithms and settings dependant on $whatever.

You can do this all of this right w/o the built-in compression, which is
my point; why have the built-in compression at all? Seems like a
home-cut solution provides more features and control with minimal
engineering. All the real engineering is done: the database and
compression libraries. All that's left are a few glue functions in C.

Well, my two pennies :)

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/