Re: [HACKERS] OR with multi-key indexes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] OR with multi-key indexes
Date
Msg-id 199808011529.LAA24697@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] OR with multi-key indexes  (Vadim Mikheev <vadim@krs.ru>)
List pgsql-hackers
> Bruce Momjian wrote:
> >
> > Here is a comment in path/indxpath.c that says they don't want to use
> > multi-key indexes with OR clauses.  Of course, we now support multi-key
> > indexes, and this code was disabled anyway because it was broken.  (In
> > fact, it was disabled by having SingleAttributeIndex() always return
> > false.
> >
> > Is there any reason we can't use multi-key indexes if the first key
> > matches our OR column?  I don't see why not.  Also, I don't know how to
>                           ^^^^^^^^^^^^^^^^^^^
> Me too.

Good.  Code restriction removed.

>
> > handle the case where we specify the first key of a multi-key index in
> > an AND clause, and specify the second key in an OR clause because the
>
> What do you mean? Example please...
>
> > AND's are handled in a separate are of the code.  Any ideas how to
> > implement this?  (Of course, the code would still use the index for the
> > AND, but I don't know how to bring the AND case into my OR index clause
> > processing area.)

    create table test (x int4, y int4);
    create index i_test on test(x,y);
    insert into test values(1,2);
    select * from test where x=3 and (y=1 or y=2);

This is going to use the i_test index, but only with key x=3, and do a
scan of the index looking for y=1 or y=2, and will not use the second
key of the index.

I don't know how to pass information to the OR code so it will know the
first part of the index is matched, and it can compare the second key.

--
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)

pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] 6.4 Aggregate Bug
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Problem with CVS access to current sources