> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Vadim Mikheev
> Sent: Tuesday, July 06, 1999 8:12 PM
> To: Tom Lane
> Cc: Thomas Lockhart; Leon; pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] Fwd: Joins and links
>
>
> Tom Lane wrote:
> >
> > I am not sure there's anything fundamentally wrong with his basic point;
> > if, say, we could find a way to construct OIDs so that a tuple could be
> > found very quickly from its OID, that wouldn't violate the relational
> > model AFAICS, and such OIDs would work fine as "links". But I don't see
> > any way to do that without either giving up UPDATE or introducing a huge
> > amount of baggage into all processes that can update tables (VACUUM
> > being the worst case, likely). Without doubt the best compromise would
> > look remarkably like an index on OID.
>
> There is no problems with UPDATE: updated tuple points to newer
> version, so we can avoid update of referencing tuples here.
> VACUUM would have to update referencing tuples (via normal
> heap_replace, nothing special) while removing old versions.
> This may cause deadlocks but we could give vacuum higher priority
> and abort others.
>
> So, vacuum is the worst case, as pointed by Tom.
> No problems with MVCC and other things.
>
What about dump/reload ?
And would vacuum be much complicated than now ?
I think vacuum is sufficiently complicated now.
Didn't these kind of annoying things let RDBMS exceed
NDBMS inspite of its low performance ?
If "link" is necessary at any cost,how about the following story ?
"link" = OID + TID
If oid pointed by TID is different from holding OID,executor resets TID using OID indices(my story needs OID
indices).
By this way we need not change vacuum/dump/reload etc.
The command to update TID-s to latest ones may be needed.
Comments ?
Hiroshi Inoue
Inoue@tpf.co.jp