Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199403261053.CAA12143@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
Message-Id: <199403261053.CAA03183@faerie.CS.Berkeley.EDU>
From: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
To: suresh@nlm.nih.gov (Suresh Srinivasan)
Cc: postgres@postgres.Berkeley.EDU, rodgers@hume.nlm.nih.gov
Subject: Re: Retrieve question [one last try]
Reply-To: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
Date: Sat, 26 Mar 94 02:53:06 -0800
Resent-To: postgres-dist@postgres.Berkeley.EDU
Resent-Date: Sat, 26 Mar 94 02:53:12 -0800
Resent-XMts: smtp

aoki@postgres.Berkeley.EDU (Paul M. Aoki) writes:
> to put it more consisely, you're absolutely right for OR clauses.

actually, to put it *really* concisely, i must have been high 
when i wrote that.  after thinking about it for a second, it
occurred to me that there was a file called orindxpath.c..
sure enough, the optimizer does consider it, at least if the 
OR'd subclauses refer to the same table.  it just goes ahead 
and uses the lousy information it has, which leaves it open to
the evil selectivity/stats pitfalls i described earlier (i.e.,
if you don't have key distribution stats, it's easy to pick an 
indexscan incorrectly or fail to use a useful index).  blah.
that being the case, i don't have a good answer to your question.

sorry for the misinformation.  (spring break is here, and not a
minute too soon..)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki