| From: | Dima Tkach <dmitry(at)openratings(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | pgsql-bugs(at)postgresql(dot)org | 
| Subject: | Re: Compund indexes and ORs | 
| Date: | 2003-06-07 17:33:58 | 
| Message-ID: | 3EE22206.4080403@openratings.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
Tom Lane wrote:
> Dmitry Tkach <dmitry(at)openratings(dot)com> writes:
> 
>>explain select * from abc where a=1 and b in (1,2);
>>Now, why  doesn't it want to use the index for the second condition???
> 
> 
> Because the expression preprocessor prefers CNF (AND of ORs) over
> DNF (OR of ANDs).  Since your WHERE clause is already CNF, it won't
> convert to DNF, which unfortunately is what's needed to produce
> a multiple indexscan.  For now you have to write something like
> 
> 	WHERE (a=1 and b=1) OR (a=1 and b=2)
> 
> to get a multiple indexscan from this.  (Actually, it would work if b
> were the first index column --- you need OR clauses that all mention
> the first index column to trigger consideration of a multiple indexscan.)
> 
> Improving this is on the TODO list, but fixing it in a reasonable way
> seems to require a major rethinking of the way multi-indexscans are
> planned.
> 
That's what I suspected... In fact, I even tried converting it to the 
DNF, and it worked...
My problem is that this was just an example, the real query is a lot 
more complicated (joining about 10 tables), and the list is about 20 
elements :-(
Dima
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2003-06-08 09:49:11 | Re: [BUGS] Detecting proper bison version before make | 
| Previous Message | Bruce Momjian | 2003-06-07 16:31:20 | Re: [BUGS] Detecting proper bison version before make |