Re: [HACKERS] compression in LO and other fields

Marc G. Fournier wrote:

> On Fri, 12 Nov 1999, Tom Lane wrote:
> > wieck(at)debis(dot)com (Jan Wieck) writes:
> > > Tom Lane wrote:

> Right now, we're dealing theory...my concern is what Jan points
> out "what it's performance impact would be"...would much harder would it
> be to extent our "CREATE TABLE" syntax to do something like:
>
> CREATE TABLE classname ( .. ) compressed;
>
> Or something similar? Something that leaves the ability to do
> this in the core, but makes the use of this the choice of the admin?

Yepp, exactly that's what I meant with making tuple
compression a per table option. Obviously, ALTER TABLE ...
must be supported too - that's simply a parser -> utility ->
flip flag in pg_class thing (90% cut&paste).

I think the part on deciding what to compress is easy,
because the flag telling if heap access should try to
compress a tuple on append (i.e. INSERT or UPDATE) has to be
in pg_class. And the content of a relations pg_class entry is
somewhere below the Relation struct (thus already known after
heap_open).

The idea was to use another bit in the tuple header to tell
if an existing heap tuple's data is compressed or not. So the
heap fetching allways looks at the bit in the tuple header,
and the heap appending looks at the flag in the relation
pointer. That's exactly what you want, no?

The major part is to make all callers of heap_fetch() and
sisters treat in memory decompressed (or from block split
reconstructed) tuples the right way.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #