Bruce Momjian wrote:
> > > I planned to use as many of PostgreSQL data structures unaltered as
> > > possible. Storing one Tuple in multiple Items should not pose too much
> > > danger on bufmgr and smgr unless they access tuple internals. (I didn't
> > > check that yet). This would mean that on disk Items do no longer
> > > correspond to Tuples. (Some of them might form one tuple).
> > >
> >
> > Hmm,we have discussed about LONG.
> > Change by LONG is transparent to users and would resolve
> > the big tuple problem mostly.
> > I'm suspicious that tuple chaining is worth the work now.
> >
> > At least a consensus is needed before going,I think.
> > Bad design would only introduce a confusion.
>
> Agreed.
Me too.
I think that only a combination of LONG attributes and split
tuples will be a complete solution.
What I'm worried about is to make the segments of a large
tuple specialized things in the main table. The reliability
of Vacuum is one of the most important things for any system
in production. While the general operation of vacuum seems to
be well known, it's requirements for atomicy of some actions
appears to be lesser. The more chunks a tuple consists of,
the more possible an abort of vacuum in the middle of their
moving becomes. So keeping the links of chained tuples fail
safe intact is IMHO an issue, a little underestimated in this
discussion.
Maybe we can split tuples in another way, must think about it
for another hour - 'til later.
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) #
