Just an update on this: queries in the 'next key' form on fields(a,b,c) only ever use the index for the first field (a). I just never noticed that before...in most cases this is selective enough. In most logical cases in multi part keys the most important stuff comes first.
Curiously, queries in the Boolean reversed form (switching and with or, etc.) find the index but do not apply any condition, kind of like an indexed sequential scan... Well, if and when the rowtype comparison can be made to work over multi part keys (and the optimizer is made to do tricks there), postgres can be made to give much better generalized ISAM access. In the meantime, I'll just troubleshoot specific cases via application specific behavior as they come up. In any case, many thanks to Greg and Tom for taking the time to pick this apart. Merlin ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
