Arbitrary tuple size - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Arbitrary tuple size
Date
Msg-id m112B9j-0003ktC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
Responses Re: [HACKERS] Arbitrary tuple size
List pgsql-hackers
Well,

    doing  arbitrary tuple size should be as generic as possible.
    Thus I think the best place to do it is down  in  the  heapam
    routines  (heap_fetch(), heap_getnext(), heap_insert(), ...).
    I'm not 100% sure but nothing should access a  heap  relation
    going  around  them.  Anyway,  if there are places, then it's
    time to clean them up.

    What about adding  one  more  ItemPointerData  to  the  tuple
    header  which holds the ctid of a DATA continuation tuple. If
    a tuple doesn't fit into one block, this will tell  where  to
    get  the  next  chunk of tuple data building a chain until an
    invalid ctid is found. The continuation  tuples  can  have  a
    negative  t_natts  to  be  easily  identified  and ignored by
    scanning routines.

    By doing it this way we could also sqeeze out some  currently
    wasted space.  All tuples that get inserted/updated are added
    to the end of the relation.  If a tuple currently doesn't fit
    into  the  freespace of the actual last block, that freespace
    is wasted and the tuple is placed into a new allocated  block
    at  the  end.  So  if  there is 5K freespace and another 5.5K
    tuple is added, the relation grows effectively by 10.5K!

    I'm not sure how to handle this with vacuum,  but  I  believe
    Vadim is able to put some well placed goto's that make it.


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

pgsql-hackers by date:

Previous
From: "Patrick Welche"
Date:
Subject: Re: [HACKERS] PATCH for pgconnection.h
Next
From: Vadim Mikheev
Date:
Subject: Re: [HACKERS] Delaying insertion of default values