=== frankban|afk is now known as frankban [16:27] wgrant: Any suggestions on speeding up the query shown in http://paste.ubuntu.com/16923480/ ? It's rather essential to the xPN vocabulary -> package cache work. I've also tried the "... AND binarypackagename.id IN (SELECT distroseriespackagecache.binarypackagename FROM ...)" strategy, which is slower. [16:28] Or perhaps we can tolerate this given that vocabulary lookups aren't generally fast-path? [16:31] It's a *lot* slower than the couple-of-milliseconds lookups in xPN though. [16:36] Hm. It would be a lot better if the planner did the name scan first. [16:40] Do I just have to do two separate queries to stop it being stupid? === frankban is now known as frankban|afk [16:42] Hm, even if I split it into separate queries the DSPC part isn't great. [16:48] Aha! Needs distroseriespackagecache (binarypackagename, archive) [16:56] OK, with that it's much better in cases where there aren't too many BPNs. If there are lots then there seems to be a tipping point where it goes back to terrible (e.g. "name LIKE '%man%'"). [16:58] Looks like it only uses distroseriespackagecache__binarypackagename__archive__idx if there aren't too many possible BPNs. [17:11] I think it will be OK if I can limit the result set. [23:40] cjwatson: Two separate queries might be necessary. What's your latest progress on that, so I can optimise it further? [23:46] wgrant: Further optimisation may not be necessary. http://paste.ubuntu.com/16934843/ with https://code.launchpad.net/~cjwatson/launchpad/package-cache-indexes/+merge/296379 [23:46] The trick seems to be pushing the LIMITs down far enough [23:46] As well as the indexes of course [23:47] Try with linux and it will probably take eleven years. [23:48] 1440ms hot [23:48] http://paste.ubuntu.com/16934912/ [23:49] Thirteen years, then. [23:52] Incidentally I wonder why I made GitRepositoryTargetWidget use BinaryAndSourcePackageNameVocabulary rather than SourcePackageNameVocabulary. Seems silly. [23:52] Not that it really helps since LaunchpadTargetWidget needs the combined one anyway, but I noticed it in passing.