At 21:09 17/01/00 -0800, Noah Friedman wrote:
>clients end up searching for. But I would guess that 128 or 256 indexes
>would satisfy our requirements for a while.
>
Eh? You _sure_ you need that many? Is your database fully normalised? I'm
really curious as to what it is your doing now! Is this to do with the
sequence of keys in an index?
>It looks to me like I could do this by adjusting the MAX_KEY parameter in
>sql/unireg.h, maybe adjusting N_MAX_KEY_LENGTH in include/nisam.h also if I
You'll need to wait for a reply from someone smarter than me I'm afraid.
>How quickly does *search* performance degrade with more indexes to the
>point where there is no benefit to having an index at all? I do not expect
>frequent inserts or deletes, but I expect many searches on arbitrary column
>sets.
>
Unless you've got a *REALLY* silly number of indices, the impact on SELECTs
is likely to be imperceptible; The real impact is when
INSERTing/UPDATEing/DELETEing or REPLACEing, since the time it takes is the
time needed to modify each affected file.
HTH
Colin
