(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 <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings