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

Поиск
Список
Период
Сортировка
От wieck@debis.com (Jan Wieck)
Тема Re: [HACKERS] Volunteer: Large Tuples / Tuple chaining
Дата
Msg-id m11xwwh-0003kGC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Volunteer: Large Tuples / Tuple chaining  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [HACKERS] Volunteer: Large Tuples / Tuple chaining  (Tom Lane <tgl@sss.pgh.pa.us>)
RE: [HACKERS] Volunteer: Large Tuples / Tuple chaining  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Список pgsql-hackers
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) #

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gunther Schadow
Дата:
Сообщение: Re: [HACKERS] UNICODE characters vs. BINARY
Следующее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] UNICODE characters vs. BINARY