On 17 Jul 2003 at 11:01, Fabian Kreitner wrote: > psql (PostgreSQL) 7.2.2 > > perg_1097=# VACUUM ANALYZE ; > VACUUM > perg_1097=# EXPLAIN ANALYZE select notiz_id, obj_id, obj_typ > perg_1097-# from notiz_objekt a > perg_1097-# where not exists > perg_1097-# ( > perg_1097(# select 1 > perg_1097(# from notiz_gelesen b > perg_1097(# where ma_id = 2001 > perg_1097(# and ma_pid = 1097 > perg_1097(# and a.notiz_id = b.notiz_id > perg_1097(# ) > perg_1097-# ;
For 31K records, seq. scan does not sound like a bad plan to me but anyway..
Im not generally worried that it uses a seq scan but that the second example (where an index on the sub select is used on a table with only 45 entries) executes more than 4 times faster. Its not a cache thing either, since i can enable seqscan again and it will run with 2300ms again.
How about
where ma_id = 2001::integer and ma_pid = 1097::integer
in above query?
I dont really understand in what way this will help the planner but ill try.
Thanks, Fabian
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
