Re: strange explain

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

Responses

Browse pgsql-hackers by date

  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