 |
Agreed. The last time this was done there were way too many indexes added and it really slowed down inserts and updates and made the schema more confusing. We've been focusing on reducing the number of queries be perform first, and then we can take a serious look at which indexes we really want. If you feel like giving more details on which columns you indexed, though, that would be useful. |
|
|
oh, just noticed you gave a link. Well if you feel like enumerating them, it might still be useful, but I guess when someone comes to do this they'll have no problem looking at the generate script. |
 |
hi, i added indexes mostly on int fields. most of the tables have one index with all fields which could be from interest. (have a other project where such indexes add a 400-800% performance burst, http://oe1app1.orf.at/index.php if somone is intrested in) Maybe someone with tons of bugs could test it and makes some performance tests. |
|
|
Interesting... that doesn't really make sense. If you have an index with all of the fields, that's just like another copy of the table - it shouldn't make things any faster. The point of an index is that you can make a b-tree, for example, of integer values or a hash-table of string values so that when you ask for a row with a particular value in that column, you can pull out the rows very quickly instead of having to do a linear search through the whole table. There are times when a query will actually be faster with a linear search than with several index searches though. And queries that do, for example "LIKE '%foo%'" aren't helped by hashtable indexes at all. Judicious use of EXPLAIN while testing indexes can be very enlightening. |
 |
Is it true that Mantis doesn't use indexes (except for PKs)?? Atleast add indexes for the most commonly used queries and you'll se a HUGE speed boost. Just do the most important ones first, if you don't have time with a more thorough analysis. |
 |
I belive most sensible indexes are added in 1.0 and onwards |
- Anonymous
