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
RE: [HACKERS] Volunteer: Large Tuples / Tuple chaining |
Список | 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 по дате отправления: