Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] data compression/encryption

From: "Maurice Gittens" <mgittens(at)gits(dot)nl>
To: "Brett McCormick" <brett(at)work(dot)chicken(dot)org>, <pgsql-hackers(at)hub(dot)org>
Subject: Re: [HACKERS] data compression/encryption
Date: 1998-04-30 06:46:22
Message-ID: 007b01bd7403$b21e5c60$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
-----Original Message-----
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

>from todo:
>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
>automagically compressed.

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 MeskesDate: 1998-04-30 07:22:56
Subject: Re: [HACKERS] ANSI error messages
Previous:From: Sbragion DenisDate: 1998-04-30 06:38:36
Subject: Re: [INTERFACES] Access'97 and ODBC

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group