I think they could be optimised further if I understood django better, but I'm going for any low hanging fruit I can find and it is making a significant difference I reckon. I tried to improve the table that summarises the dose and times for the fluoro detail page for example, but I got stuck so reverted.
I'm confused. I've exhausted all query optimisations I can think of, and now have 58 queries for my current dev home page. But the last commit was 40...
Also, accidentally did a code reformat, which is unfortunate as it makes comparisons hard.
Update on progress (or lack of) for home page rendition. Unfortunately, despite reducing the number of queries from 94 down to 39 on my development environment laptop, when testing with a real (large) database the version with fewer queries takes longer :-(
Using the database used for the tests of the filtered and detail pages above, I get the following approximate stats. The first three are from the Django Debug Toolbar, the last from Chrome's tools.
Number of queries
SQL time (ms)
CPU time (ms)
Chrome Wait (s)
I have been experimenting with adding indexes, and whilst I can shave a second or two off the 484 branch time, I can't get down to the develop times (which are the same as the 0.7.4 times). It seems that in this case doing more queries is cheaper than doing fewer!
There are obviously some database optimisations to be made, and whilst my knowledge of the database queries is improving, so far I haven't been able to get over the fact that we need to the hash join between the GeneralEquipmentModuleAttr table and the UniqueEquipmentNames table, and then do a sequential scan on the result. With 11,805 rows and 251,111 rows in this example for the join and the scan respectively, that takes 100 ms and 40 ms to plan and execute. For one query of 58, many of which are very similar to this one.
If anyone understands this stuff better than I do, please shout!