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

data compression/encryption

From: Brett McCormick <brett(at)work(dot)chicken(dot)org>
To: pgsql-hackers(at)hub(dot)org
Subject: data compression/encryption
Date: 1998-04-30 02:27:09
Message-ID: 13639.57260.727612.373168@abraxas.scene.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

pgsql-hackers by date

Next:From: Brett McCormickDate: 1998-04-30 02:36:31
Subject: Re: [HACKERS] removing the exec() from doexec()
Previous:From: The Hermit HackerDate: 1998-04-30 02:20:52
Subject: Re: [HACKERS] removing the exec() from doexec()

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