Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
От | Christopher Kings-Lynne |
---|---|
Тема | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
Дата | |
Msg-id | 3F77ABA0.4070600@familyhealth.com.au обсуждение исходный текст |
Ответ на | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
Список | pgsql-hackers |
You could just as easily argue that the lack of integrity testing at data load time was equally a bug. I think we need someway of telling postgres to suppress a foreign key check. The main problem is that the foreign key column is often not indexed. Chris Bruce Momjian wrote: > Tom Lane wrote: > >>Bruce Momjian <pgman@candle.pha.pa.us> writes: >> >>>Tom Lane wrote: >>> >>>>Well, we haven't even *got* a proposed patch yet, but yeah we should >>>>tread carefully. >> >>>OK. What releases had this slow restore problem? >> >>We introduced it in 7.3 --- before that, FKs were simply dumped as >>"create trigger" commands, and there was no check overhead. So arguably >>it is a bug; a performance bug maybe, but that's still a bug. No one >>has yet gone through a dump/reload cycle in which they had to face this >>penalty. > > > Now that is a strong argument. I knew you would find one. :-) >
В списке pgsql-hackers по дате отправления: