RE: [HACKERS] Volunteer: Large Tuples / Tuple chaining

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