From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Pgsql Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: strange explain |
Date: | 2002-05-14 06:37:13 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961DCA@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> EXPLAIN
> tour=# explain analyze select * from tours where
> ( operator_id in (2,3,4,5,7) and type_id = 4 ) or
> ( operator_id = 8 and type_id = 3);
> NOTICE: QUERY PLAN:
>
> Index Scan using type_idx, type_idx, type_idx, type_idx, type_idx, type_idx on tours (cost=>
> 0.00..12.25 rows=1 width=1091) (actual time=0.27..0.27 rows=0 loops=1)
> Total runtime: 0.44 msec
Actually this plan looks very strange to me. One would expect it to only use
type_idx twice (in lack of a better index (type_id, operator_id)).
Fetch all rows with type_id=4 and then filter the result on operator_id in (...),
then do type_id=3 and filter operator_id=8.
Seems there is room for another performance improvement here :-)
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2002-05-14 07:52:55 | Re: [HACKERS] Bug #659: lower()/upper() bug on |
Previous Message | Jean-Michel POURE | 2002-05-14 06:35:12 | Re: [HACKERS] Bug #659: lower()/upper() bug on |