Re: [HACKERS] Fwd: Joins and links

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Leon <leon(at)udmnet(dot)ru>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Fwd: Joins and links
Date: 1999-07-06 11:12:29
Message-ID: 3781E49D.96036773@krs.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Vadim

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vadim Mikheev 1999-07-06 11:26:18 Re: AW: [HACKERS] Fwd: Joins and links
Previous Message Zeugswetter Andreas IZ5 1999-07-06 07:48:36 AW: [HACKERS] Fwd: Joins and links