Re[2]: [HACKERS] Fwd: Joins and links

From: Leon <leon(at)udmnet(dot)ru>
To: Clark Evans <clark(dot)evans(at)manhattanproject(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re[2]: [HACKERS] Fwd: Joins and links
Date: 1999-07-06 14:40:26
Message-ID: 2819.990706@udmnet.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-07-06 15:04:59 Re: Re[2]: [HACKERS] Fwd: Joins and links
Previous Message Vadim Mikheev 1999-07-06 13:54:25 Re: [HACKERS] Fwd: Joins and links