Re: [HACKERS] LONG
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] LONG |
Дата | |
Msg-id | 7475.945054016@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | RE: [HACKERS] LONG ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
Re: [HACKERS] LONG
RE: [HACKERS] LONG |
Список | 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. 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. It would be a little tricky to write out a tuple plus its expansion tuples and have them all know each others' CTIDs; the CTIDs would have to be assigned before anything got written. And VACUUM would need a little extra logic to update these things. But those are very localized and IMHO solvable problems, and I think the performance advantages would be significant... > What is wrong with separate VACUUM ? > VACUUM never changes OIDs and XIDs(after MVCC). I believe VACUUM does assign its own XID to tuples that it moves, so that a crash during VACUUM doesn't corrupt the table by leaving multiple apparently-valid copies of a tuple. We'd have to figure out how to accomplish the same result for expansion tuples. regards, tom lane
В списке pgsql-hackers по дате отправления: