Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
От | Stephan Szabo |
---|---|
Тема | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
Дата | |
Msg-id | 20030929173828.L2493@megazone.bigpanda.com обсуждение исходный текст |
Ответ на | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
(I think my previous attempt got aborted by a lost connection, so a message like this may arrive twice) On Mon, 29 Sep 2003, Tom Lane wrote: > Stephan Szabo <sszabo@megazone.bigpanda.com> writes: > >> Hm. Don't suppose you were using EXPLAIN ANALYZE so we could see what's > >> happening? This is clearly a planner failure, although I'm unsure if we > >> can expect the planner to get the right answer with no pg_statistic entries. > > > The left join one seems to give me values like the following: > > There are some fishy row estimates in here: > > > -> Index Scan using pktest_a_key on pktest (cost=0.00..52.00 > > rows=1000 width=8) (actual time=17.82..1609.97 rows=10000 loops=1) > > The system definitely should be expected to have the accurate row count > for the PK table, since an index should have been created on it (and we > do do that after loading the data, no?). It is possible that it'd have > the default 1000 estimate for the FK table, if there are no indexes at > all on the FK table; otherwise it should have the right number. It's > not real clear to me what conditions you're testing under, but the > estimates in the plans you're quoting aren't consistent ... Also, the sequence was basically: CREATE TABLE pktest(a int, b int, unique(a,b)); CREATE TABLE fktest(b int, c int); COPY pktest FROM STDIN; ... COPY fktest FROM STDIN; ... <run some tests I didn't mention here> CREATE INDEX fki on fktest(b,c); <run the above test> With stopping and restarting the server involved and running the tests multiple times.
В списке pgsql-hackers по дате отправления: