Re: [HACKERS] compression in LO and other fields

Marc G. Fournier wrote:

> On Fri, 12 Nov 1999, Tom Lane wrote:
> > wieck@debis.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@debis.com (Jan Wieck) #