Hmm a very interesing theoretical topic...
Wouldnt make sense to tie this in with the implementation of a Foriegn Key?
So when the foriegn key is defined you create anoter index that stores all
the relevant child to parent relationships and can be used to speed up that
access since it obviously will be a primary access route (else thay wouldnt
have defined it). I would think it could be used then to check the Foreign
Key integrity and used to help maintain/construct clustered tables...
And Bruce you sound bitter about MVCC :)
>-----Original Message-----
>From: Leon <leon@udmnet.ru>
>To: David Warnock <david@sundayta.co.uk>; pgsql-general
><pgsql-general@postgreSQL.org>
>Date: Monday, July 05, 1999 12:26 PM
>Subject: Re[2]: [GENERAL] Joins and links
>
>
>>Hello David,
>>
>>Monday, July 05, 1999 you wrote:
>>
>>D> If you are interested in other solutions that do not involve adding
>>D> record number support (which I personally still feel to be a mistake in
>>D> a set orientated dbms)
>>
>>Why? There will be no such field as "record number", the only
>>place where it can exist is the field which references another
>>table. I can quite share your feeling about wrongness of
>>physical-oriented things in abstract tables, but don't
>>plain old indices deal with physical record numbers? We could
>>do the same - hide the value stored in such field and only
>>offer the user ability to use it in queries without knowing
>>the value.
>>
>>D> then have you considered an application server
>>D> linked to triggers.
>>
>>Unfortunately, every day user demands new types of reports
>>for financial analysis. And nobody knows what will be user's
>>wish tomorrow.
>>
>>And, besides, it is not only my personal wish. What I am
>>proposing is huge (dozen-fold) performance gain on widespread
>>tasks. If you implement this, happy users will erect a gold
>>monument to Postgres development team.
>>
>>Best regards, Leon
