Re: Foreign keys for non-default datatypes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Foreign keys for non-default datatypes
Дата
Msg-id 9408.1141431742@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Foreign keys for non-default datatypes  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Ответы Re: Foreign keys for non-default datatypes  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Re: Foreign keys for non-default datatypes  (Michael Glaesemann <grzm@myrealbox.com>)
Список pgsql-hackers
BTW, I had another thought about this: if we go this way, then the plans
associated with RI check queries would essentially always be trivial
index lookups (for everything except RI_Initial_Check).  It'd be within
the realm of feasibility to throw away the current cached-plan RI
infrastructure and simply do direct indexscans, in the style that we
currently use for most system-catalog accesses.  I have never done any
performance testing or profiling of routine foreign-key check operations
but I should think that this would be really significantly faster ---
and it'd let us get rid of some ugly warts that we've had to plaster
onto SPI and the executor to support RI semantics, such as the
"crosscheck snapshot" cruft.

If we did this then RI checks would no longer be subvertible by rules or
user triggers.  Although I've been heard to argue that that's a feature,
I think the majority of people feel it's a bug, and wouldn't be sorry to
see it go.

Comments?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Problemas with gram.y
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: Foreign keys for non-default datatypes