Comment 8 for bug 742916

I don't know enough about our schema here to know if we can assume monotonically increasing revision ids mapping to graph range queries. I think we can't.

Aaron was suggesting a revno - aka. 'BranchRevision.sequence' constraint, not a revision constraint.

That said, its worth looking at the performance of this query.

It has three parts - two CTE's and the main body.

 CTE first - estimated to find one row but examine up to 20K. cold cache we seem to spend about 2ms per cold row, so thats up to 40 seconds cold (based on planner stats).
Its doing an index scan on revisionnumber_branch_sequence_unique which is (branch, sequence).
This considered 103 rows.
For each row it looked up the revision id directly to check the date. - it was fast because only 103 rows existed in the branch: its a very small branch :)

CTE last is very similar.

So the costs for both first and last in your formulation are potentially very high.