Re: [HACKERS] LONG
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] LONG |
Дата | |
Msg-id | 199912130325.WAA14266@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] LONG (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > There are so many mails for me to follow about this issue. > > For example,what's the conclusion about the following ? > > I don't think it's concluded yet... > > > Why is CTID needed ? Is it necessary to know "primary" tuples from > > out-of-lines values ? > > It seems to me that the primary tuple should store CTIDs of the > out-of-line segment(s) it's using. That way, we need no index at > all on the expansion relation, which would clearly be a win. That could be bad. Vacuum moving expired entries in long_ tables would need to update the ctids in the primary relation, which would be a mess. Also, I can see an 16MB relation using 8k of stored ctids. Entries over 16MB would be overflow, causing problems. I think an index and tradition access will be just fine. > > My thought was that if the expansion tuples stored CTIDs of their > primary tuples, then it would be practical to have VACUUM consult > the primary tuples' xact status while vacuuming the expansion. > That way, we'd have no need to update expansion tuples when changing > xact status of primary tuples. But I think Jan has something else > in mind for that. Then you need to have a way to point back to the primary table from the long_ table. Doesn't seem worth it. Also, I am questioning the use of compressed for long tuples. I often don't want some compression happening behind the scenes. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: