From: Brett McCormick <brett(at)work(dot)chicken(dot)org>
To: pgsql-hackers(at)hub(dot)org <pgsql-hackers(at)hub(dot)org>
Date: donderdag 30 april 1998 10:42
Subject: [HACKERS] data compression/encryption
>Allow compression of large fields or a compressed field type
>I like this idea. Should be pretty easy too. Are we interested in
>putting this in the distribution, or as a contrib? I could easily
>create a compressed field type like the text type. However, how do
>you actually get the data in there? Assuming you're trying to get
>around the 8k tuple limit, there's still the 8k query length. Does
>copy do ok with >8k tuples (assuming the resulting tuple size is < 8k).
>Compression of large objects is also a good idea, but I'm not sure how
>it would be implemented, or how it would affect reads/writes (you
>can't really seek with zlib, which is what I would use).
>I've also been thinking about data encryption. Assuming it would be
>too hard & long to revamp or add a new storage manager and actually
>encrypt the pages themselves, we can encrypt what gets stored in the
>field, and either have a type for it, or a function. What about the
>idea of a 'data translator', a function which would act as a filter
>between the in/out functions and the actual storage of data on disk/in
>memory. So that it could be applied to fields which would then be
I've been looking at how information is stored at the lowest level in
and if I'm not mistaken compressing and/or encrypting of items on a
page is doable. Since items can be shuffeled around on a page without
changing their tid.
I haven't given much thought to how such functionality could be presented
to the user.
pgsql-hackers by date
|Next:||From: Michael Meskes||Date: 1998-04-30 07:22:56|
|Subject: Re: [HACKERS] ANSI error messages|
|Previous:||From: Sbragion Denis||Date: 1998-04-30 06:38:36|
|Subject: Re: [INTERFACES] Access'97 and ODBC|