allocate-revision-karma.py is being very slow post the postgres 8.4 upgrade

Bug #658115 reported by Steve McInerney
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
New
Undecided
Unassigned

Bug Description

when killed had been running for ~ 25 hours.
stub suggests that:

<stub> SELECT Revision.date_created, Revision.gpgkey, Revision.id, Revision.karma_allocated, Revision.log_body, Revision.revision_author, Revision.revision_date, Revision.revision_id FROM Revision, RevisionAuthor, ValidPersonCache WHERE Revision.revision_author = RevisionAuthor.id AND RevisionAuthor.person = ValidPersonCache.id AND NOT Revision.karma_allocated AND EXISTS (SELECT true FROM Branch, BranchRevision WHERE BranchRevisio
<stub> Slooooow query
<stub> We will need to rewrite it for 8.4 - subselects are always a pain, and unfortunately we seem to have used them to optimize for PG 8.3

do have a gcore on loganberry; but the above sounds more useful to start with.

Steve McInerney (spm)
tags: added: canonical-losa-lp
summary: - allocate-revision-karma.py is beng very slow post the postgres 8.4
+ allocate-revision-karma.py is being very slow post the postgres 8.4
upgrade
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.