Tom Lane wrote:
> wieck@debis.com (Jan Wieck) writes:
> > I think that only a combination of LONG attributes and split
> > tuples will be a complete solution.
>
> If we can do a good job with long attributes, I really think we
> will not need to have split tuples too.
I really hope so, because there will be very severe problems
coming up with a real tuple split at arbitrary cut points
that can occur somewhere in the middle of an attribute.
Arbitrary cut points are the only way to support single
values over BLKSIZE.
Just to tell one problem, the scan key tests during
heap_getnext() are handed down into heapgettup() and
performed with HeapTupleSatisfies, a macro using the in
buffer tuple here. IIRC it was turned into a macro in one of
our last releases for performance reasons.
If now faced with a tuple living in multiple pages, these
checks will need to reconstruct the tuple in memory, to
concatenate the attributes well again.
This now needs to lock multiple buffers at once during
heapgettup(), where I'm not sure if they must all stay with
the bumped refcount when returning the tuple or not. So
ReleaseBuffer() might need to be changed into something,
where the HeapTuple remembers all the buffers that where
locked for it.
Also this separate ReleaseBuffer() reminds me, that there are
some places in the backend that assume a tuple returned by
heap AM allways is in a buffer! But that can't be true any
more, because a buffer allways has BLKSIZE.
> I think the effort this would take would be *much* more profitably
> spent on tuning the LONG-attribute support. If we can make that
> fast and robust, we will have very few complaints.
*MUCH*!
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) #