Greg Stark wrote:
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
> > TODO item?
>
> On that note several prior conversations I had here ended with WIBNI
> conclusions that really ought to be TODO items, in my humble opinion. Two come
> to mind off the top of my head resulting in:
>
> . "SELECT * FROM x JOIN y USING (b) WHERE a=?" could use an index on y(a,b)
> since for a constant value of "a" the index traversal would be effectively
> equivalent just be "b". This could result in an efficient merge join
> avoiding an unnecessary sort.
>
> . The semantics for row-value expressions is wrong. (a,b) < (x,y) should be
> true if a<x or if a=x and b<y. Currently it expands to a<x and b<y.
>
> . Fix row-value expression handling to not depend on the operator names and
> instead use btree access method strategy values instead, allowing row-value
> expressions on other operators with <,=,> behaviour (ie btree indexable
> behaviour).
>
> . Allow multi-column indexes to be used to optimize row-value expressions. Ie,
> allow a btree index on a,b to be used to execute an expression like (a,b) <
> (x,y).
I have not heard of any of those so I have not been actively excluding
them from the TODO list. However, I need someone with optimizer
experience to make a recommendation.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073