> Bruce Momjian wrote:
>
> > I have worked with Vadim privately on the remaining OR clause index
> > issues, and I am done. Please start testing, everyone.
> >
>
> Ran a few tests last night. So far, works great for single, non-internal,
> attributes. However, I was not able to get the query to use the table's oid
> index when such an index existed. Did a VACUUM ANALYZE before the query.
> Will be doing some more testing over the next few days.
Try:
test=> explain select * from test where oid = 3::oid or oid = 4::oid;
NOTICE: QUERY PLAN:
Index Scan using i_test2 on test (cost=4.10 size=1 width=4)
Thomas will have to deal with this before 6.4. The auto-casting of type
oid is not working.
>
> Have not tried any mult-part keys. Will this patch handle a small number of
> OR'ed multi-part keys?
This is another item that I think does not work. The code handles AND
and OR separately, making this hard to handle:
key1 = 7 and (key2 = 99 or key2 = 100)
It will use the first part of the key to get key1 = 7, but recognize
that the first part of the key was matches and use the key2 part. I am
going to study the optimizer code for 6.4, so I may be able to get it
working. Not sure yet.
It will certainly use the first part of a multi-part key if the first
key is the one matching the OR clause.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)