Merge lp:~james-w/python-oops-tools/recent-oopses into lp:python-oops-tools
| Status: | Needs review |
|---|---|
| Proposed branch: | lp:~james-w/python-oops-tools/recent-oopses |
| Merge into: | lp:python-oops-tools |
| Diff against target: |
142 lines (+28/-58) 2 files modified
src/oopstools/oops/templates/report.html (+8/-23) src/oopstools/oops/views.py (+20/-35) |
| To merge this branch: | bzr merge lp:~james-w/python-oops-tools/recent-oopses |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Natalia Bidart (community) | Approve | ||
| python-oops-tools reviewers | Pending | ||
|
Review via email:
|
|||
Commit message
Modify the recent oopses query to perform better with lots of oopses.
When there is a report with many prefixes, and the most recent oopses are
not for any of those prefixes postgres will pick a query plan that performs
poorly (not using the most selective index, assuming that the prefix ids
are distributed fairly uniformly through the oopses.)
We instead trick postgres in to using the more selective index using a window
function. Thanks to stub for the query.
We do a second query to load all the infestations for these oopses, to prevent
the ORM from doing 50 queries as we iterate over the list of oopses.
We also drop the pagination because it is not as simple to implement with the
raw query. It could be re-instated if it was really needed, but usually
I find looking at the most recent 50 oopses is sufficient.
Lastly, I re-ordered the columns in the oops listing, to put the oops
first as that is usually what you want to click on. I also dropped the linking
of the URL, as the escaping meant that it never worked, and the URL is often
not something you can simply click on either. The fact that the URL was first
in the table and a link meant that I often clicked on that rather than the
oops, wasting time.
Description of the change
Hi,
This is a few changes to hopefully improve the performance of some recent
oops views. The commit message has all the details.
Thanks,
James
| Launchpad PQM Bot (launchpad-pqm) wrote | # |
| Launchpad PQM Bot (launchpad-pqm) wrote | # |
| Launchpad PQM Bot (launchpad-pqm) wrote | # |
Unmerged revisions
- 59. By James Westby
-
Correct the variable name.
- 58. By James Westby
-
Revert to old python syntax until tests are run on a modern python.
- 57. By James Westby
-
Use more expressions. Thanks nessita.
- 56. By James Westby
-
Modify the recent oopses query to perform better with lots of oopses.
When there is a report with many prefixes, and the most recent oopses are
not for any of those prefixes postgres will pick a query plan that performs
poorly (not using the most selective index, assuming that the prefix ids
are distributed fairly uniformly through the oopses.)We instead trick postgres in to using the more selective index using a window
function. Thanks to stub for the query.We do a second query to load all the infestations for these oopses, to prevent
the ORM from doing 50 queries as we iterate over the list of oopses.We also drop the pagination because it is not as simple to implement with the
raw query. It could be re-instated if it was really needed, but usually
I find looking at the most recent 50 oopses is sufficient.Lastly, I re-ordered the columns in the oops listing, to put the oops
first as that is usually what you want to click on. I also dropped the linking
of the URL, as the escaping meant that it never worked, and the URL is often
not something you can simply click on either. The fact that the URL was first
in the table and a link meant that I often clicked on that rather than the
oops, wasting time.
Looks good!