Closed Bug 624542 Opened 14 years ago Closed 12 years ago

probably faster queries for username, collection, MAX(modified) [python]

Categories

(Cloud Services Graveyard :: Server: Sync, enhancement)

x86_64
Linux
enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: tarek, Assigned: rfkelly)

References

Details

(Whiteboard: [php: 606018][qa-])

We need to check that Python uses the same query than PHP see bug 606018
Now that loadtesting infra is rounding into shape, we should bench

SELECT wbo_a.modified FROM %(wbo)s AS wbo_a, %(wbo)s WHERE wbo_a.username=%(wbo)s.username AND wbo_a.collection=%(wbo)s.collection ORDER BY wbo_a.username DESC, wbo_a.collection DESC, wbo_a.modified DESC LIMIT 1

vs

SELECT max(modified) from %(wbo)s where username = :username and collection = :collection
Assignee: tarek → nobody
Severity: normal → enhancement
Whiteboard: [php: 606018] → [php: 606018][qa-]
Assignee: nobody → rkelly
Blocks: 784598
it's been months - can I close this bug or is it still relevant ?
Flags: needinfo?(rfkelly)
Since we mostly use memcache for dealing with the timestamps in production, I'm not sure there's much value in micro-optimizing this query.

FWIW, we are currently using the "SELECT MAX(modified)" variant from above, but all code paths that would execute it appear to hit memcache in production.  I'm happy to leave it at that unless Ops feel this could use further work.
Flags: needinfo?(rfkelly) needinfo?(rfkelly) → needinfo+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Product: Cloud Services → Cloud Services Graveyard
You need to log in before you can comment on or make changes to this bug.