Bruce Momjian wrote:
> > 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.
Yes, Vadim, putting a flag into the bits already there to
tell it is much better. The information that a particular
tuple is an extension tuple should also go there instead of
misusing t_natts.
>
> I agree this is the way to go. There is nothing I can think of that is
> limited to how large a tuple can be. It is just accessing it from the
> heap routines that is the problem. If the tuple is alloc'ed to be used,
> we can paste together the parts on disk and return one tuple. If they
> are accessing the buffer copy directly, we would have to be smart about
> going off the end of the disk copy and moving to the next segment.
Who's accessing tuple attributes directly inside the buffer
copy (not only the header which will still be unsplitted at
the top of the chain)?
Aren't these situations where it is done restricted to system
catalogs? I think we can live with the restriction that the
tuple split will not be available for system relations
because the only place where the limit hit us is pg_rewrite
and that can be handled by redesigning the storage of rules
which is already required by the rule recompilation TODO.
I can't think that anywhere in the code a buffer from a user
relation (except for sequences and that's another story) is
accessed that clumsy.
>
> The code is very clear now about accessing tuples or tuple copies.
> Hopefully locking will not be an issue because you only need to lock the
> main tuple. No one is going to see the secondary part of the tuple.
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) #