Re[2]: [HACKERS] Fwd: Joins and links
От | Leon |
---|---|
Тема | Re[2]: [HACKERS] Fwd: Joins and links |
Дата | |
Msg-id | 2819.990706@udmnet.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Fwd: Joins and links (Clark Evans <clark.evans@manhattanproject.com>) |
Список | pgsql-hackers |
Hello Clark, Tuesday, July 06, 1999 you wrote: C> Interesting idea. You are re-introducing some of the C> hierarchical database ideas, is this right? Here is C> what I'm receiving, could you correct me if I'm C> mis-understanding? (much of this you did not say...) Strictly speaking, this is neither hierarchical nor network database. It is not hierarchical because cyclic graphs are allowed (when tables reference one another, maybe through some intermediate table). And it is not network because there is not some weird restriction put on network database. (textbook says in network database one referenced tuple must be at most in one link of certain link type) C> In this proposal, in addition to carrying a primary key C> for a referenced table, tuples in the referencing table C> will also have a place to record the physical address C> of each referenced tuple. I have read description carefully. I am afraid that MVCC will break your scheme, because referencing tuple must have a way to reach all versions of foreign updated tuple. If you update the referencing field, all other versions of foreign tuple are lost. It seems the only way to satisfy MVCC is to chain updated foreign tuples with subsequent VACUUM. That's because there is no need of indices, as soon as the need of them is only during VACUUM. Best regards, Leon
В списке pgsql-hackers по дате отправления: