| | I can't attach diff to valentin's review, so here's a new one. |
| |
|
| | Optimized monitor queries when there are only filters related to ia_job table. |
| |
|
~ | | Changed ia_job indexes from (, submit_time) to (, id). When using a large offset mysql queries are very slow even when using index if not all selected data is in the index. |
| ~ | Changed ia_job indexes from (, submit_time) to (, id). |
| |
|
~ | | When filters are only related to ia_job we do a SELECT id FROM ia_job query which uses the available indexes to return the job ids fast and ordered properly and then do the full query with a WHERE ID in (...). |
| ~ | When using a large offset mysql queries are very slow even when using index if there are a lot of other fields in the SELECT. When filters are only related to ia_job we do a SELECT id FROM ia_job query which uses the available indexes to return the job ids fast and ordered properly and then do the full query with a WHERE ID in (...). |
| |
|
| | There is a great performance increase for all queries for which we had ia_job indexes but were slowed down by mysql's poor limit handling. |
| |
|
~ | | (Valentin: what you were proposing was much more complicated to code and didn't actually work ... when selecting with where clauses (for example compiler_id), results aren't always sorted by id, so reversing the results doesn't work) |
| ~ | Benchmarks: http://hackers.devnet.ro/wiki/Benchmarks |
| + |
|
| + | The monitor?round=arhiva&first_entry=100000 is still slow, but I think this is because round is a varchar(64) and thus the index_key is pretty big. If we add numeric ids to round this should work a lot better too (but that's for another patch). |