Tom Lane wrote: > The only reason the planner should choose a single-column index over > using the first column of a multi-column index is that the latter index > is likely to be physically larger and thus require more I/O to access. > So, there's no penalty in the cost calculations other than the > number-of-blocks-of-I/O estimated from the physical index size.
So is a multi-column index really just two separate indexes with a constraint added if necessary? I guess I had an idea in my head that it would be something like an index on the concatenation of the two fields. > It > would be interesting to see the reltuples and relpages stats from > pg_class for your single- and multi-column indexes. It's easy to reverse the process. How would I get those stats? > It's actually a standard recommendation that you not bother with an > index on a single column x if you also have one on (x,y). Thanks- that will make my app a bit more efficient. (But now I've got to go back & work on tuning my query again because this apparently wasn't the source of the poor performance.) -Nick ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
