>> Herouth Maoz wrote:
>>
>> > Maybe I'm missing the point here, but it seems to me that if
>> > you simply use indices not as key definitions but as query
>> > accelerators (as in "index the living daylights out of"), then
>> > you may as well define a separate index on each and every
>> > field. Why do multiple-field indices in such a case?
>>
>> Why do multi-field indexes? Umm. How about to avoid doing a sequential
>> scan? If your query depends on multiple fields then once you've found
>> the set based on the first index you would have to sequential scan that
>> subset based on the second condition, unless you have a multi-field
>> index.
I suspect that Herouth was being a little facetious here. The bottom line
is that multi-column indices are necessary for indices other than the
primary
key, and shouldn't be limited to seven fields. However, in creating a
database
that can handle more than 7 fields in indices, there is some overhead built
in.
Thus, it should be something that the administrator can decide. There are
normally quite special reasons for wanting more than 7 fields in an index,
and
if you make it a pain to add the functionality to a PGSQL server, then
people will
rather design their dbs properly. However, in those cases where it is
absolutely
necessary, the functionality will at least be available.
And I daresay that this option will be used when compiling a server to
handle
warehouses.
MikeA
