Greg Stark wrote: > > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
