At 11:17 17.07.2003, Shridhar Daithankar wrote:
On 17 Jul 2003 at 11:01, Fabian Kreitner wrote:
> psql (PostgreSQL) 7.2.2
> perg_1097=# VACUUM ANALYZE ;
> 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.


---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to