From: | Fabian Kreitner <fabian(dot)kreitner(at)ainea-ag(dot)de> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: index / sequential scan problem |
Date: | 2003-07-17 11:12:10 |
Message-ID: | 5.1.0.14.0.20030717130132.0397b6b0@195.145.148.245 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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 ;
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabian Kreitner | 2003-07-17 11:13:06 | Re: index / sequential scan problem |
Previous Message | Vincent van Leeuwen | 2003-07-17 10:14:16 | Re: Hardware performance |