> -----Original Message-----
> From: Jan Wieck [mailto:wieck@debis.com]
> Sent: Wednesday, December 15, 1999 3:45 AM
>
> 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.
>
There exists another related problem.
Vacuum could hardly move big tuples if some tuples of each page
live long. Though we have to move a long tuple at once,there won't
be so many clean pages.
Probably vacuum couldn't move even a 8K tuple in some cases.
The problem is already there,more or less.
But it seems very difficult to solve this problem without giving up
to preserve consistency in case of a crash.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp