Comment 5 for bug 260140

Firstly I'd like to document the intent of this feed. It is not to give a complete view into the order of revisions being noticed by Launchpad. It is used to indicate I view of who is doing what. We definitely want to order the feed by revision_date, not Revision.datecreated or some BranchRevision.id. It isn't really going to matter if we miss some. Perhaps we will have to return more than 25 revisions for some projects or project groups.

> A Revision needs to appear in the feed when Launchpad becomes aware of it,
> not possibly skipped altogether because the actual commit was made some
> time in the past and the branch only just pushed to somewhere Launchpad
> can see it. So the feed should display the most recently uploaded revisions
> rather the most recent commits that happen to have been mirrored to Launchpad.

I strongly disagree with this. The intent is to show what has happened recently, not necessarily what happened six months ago that Launchpad has just been told about.

The primary issue is that the feed is timing out for products without many revisions. The question becomes "how can we stop this?" One thing to identify is what the cut off is before the postgresql query analyser chooses what we consider the correct plan. If it is on number of branches, or number of revisions, we could do object traversal directly from the branches and it would be quick enough.

Given that the "correct" query plan is fast, how can we identify what the "cut off" is?

As far as how to structure a query, can we do something like this:

1) Filter the Branch table on product, private, whatever to get a reduced set.
2) Using the reduced Branch set, join with BranchRevision, but get destinct revision ids. Hopefully this would reduce the number of revisions for something like bzr to the 20k or so in the ancestry.
3) Those are then joined across Revision, and ordered.

Can this be done?