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
