Re: [HACKERS] LONG

Bruce Momjian wrote:

> In fact, you may decide to just extent varchar() and text to allow use
> of long tuples.  Set the varlena VARLEN field to some special value like
> -1, and when you see that, you go to pg_long to get the data.  Seems
> very easy.  You could get fancy and keep data in the table in most
> cases, but if the tuple length exceeds 8k, go to all the varlena fields
> and start moving data into pg_long.  That way, a table with three 4k
> columns could be stored without the user even knowing pg_long is
> involved, but for shorter tuples, they are stored in the main table.

    So  you  realized  most  of  my explanations yourself while I
    wrote the last mail.  :-)

    No, I don't intend to change anything on  the  existing  data
    types.  Where should be the limit on which to decide to store
    a datum in pg_long?  Based on the datums size? On  the  tuple
    size  and  attribute  order,  take one by one until the tuple
    became small enough to fit?

    Maybe  we  make  this  mechanism  so  general  that   it   is
    automatically applied to ALL varsize attributes? We'll end up
    with on big pg_long where 90+% of the databases content  will
    be stored.

    But  as  soon as an attribute stored there is used in a WHERE
    or is subject to be joined, you'll see why not (as said, this
    type  will  NOT  be enabled for indexing). The operation will
    probably fallback to a seq-scan on the main  table  and  then
    the attribute must be fetched from pg_long with an index scan
    on every single compare etc. - no, no, no.

    And it will not be one single pg_long table. Instead it  will
    be a separate table per table, that contains one or more LONG
    attributes.  IIRC, the TRUNCATE functionality was implemented
    exactly  to  QUICKLY  be able to whipe out the data from huge
    relations AND get the disk space  back.  In  the  case  of  a
    central  pg_long, TRUNCATE would have to scan pg_long to mark
    the tuples for deletion and vacuum must be run to really  get
    back  the  space.  And a vacuum on this central pg_long would
    probably take longer than the old DELETE, VACUUM of  the  now
    truncated table itself. Again no, no, no.


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) #