[00:00] Hmmm, getting there. [00:03] I'm not quite sure why it's choosing the bad plan for the source query. [00:03] But I have it reliably down around 10ms hot, and not toooo much worse cold. [00:04] Which will probably do. [00:08] Weird. [00:08] But that's 4-50ms without any particularly weird indices. Possibly nicer than my other attempt. [00:11] Oh, what did I miss? [00:12] http://paste.ubuntu.com/16935503/ [00:12] Main win was deconfusing the planner by pre-materialising main_archive_ids. [00:12] But that only got it down to 100ms. [00:12] Which isn't good enough for me. [00:13] The last query probably wins here. I don't understand exactly why the planner wanted the index that way, since it's only 3x faster, but it works. [00:14] cjwatson: Are you copying the definition of what it means to search from the existing vocab? [00:14] Because this definition of search is pretty weird. [00:14] Sort of; this was from my rewritten vocabs. [00:14] Can we just use DSPC.name instead of going through xPN at all? [00:14] See the third query. [00:15] That was my attempt at that. [00:15] It works well, but needs an extra extension (installed by default, just not in the DB) [00:15] The indexes are all in place on DF if you want to experiment. [00:16] Ah right. You could do it for DistroSeriesPackageCache.name as well I think. [00:16] (btree_gin lets us include an integer in a GIN index, which isn't normally possible) [00:16] Yeah, the same sort of thing applies there. [00:16] But that seems to be planned sensibly anyway. [00:16] Aaand you could not use DSPC at all. [00:16] Er, not use DistroSeriesPackageCache at all, that is. [00:17] Since we have the binary names in a column on the other table. [00:17] Bit harder to pick out, but true. [00:17] Not going to experiment now, since bedtime. [00:17] This query is pretty weird since it prefers all substring-matching source names, then all substring-matching matching binary names. [00:17] A good plan. [00:17] Night. [00:20] (otoh the weirdness makes the query quite fast in the primary archive case, since it can just run straight down SPN(name) and return the first 10 it finds that exist. probably not so fast in a PPA.) [00:25] Er, no, that was my hacked query, I guess. the ORDER BY name at the end prevents that. === mup_ is now known as mup === \b is now known as benonsoftware