launchpad-dev team mailing list archive

[William Grant <william.grant@xxxxxxxxxxxxx>]

Hi everyone,

As part of the Better Privacy project I'm rewriting bug search to use
the new BugTaskFlat table. This should make most bug searches very fast,
as well as cleaning up the code a bit.

But as I refactor lp.bugs.model.bugtasksearch, I notice that there are
some mildly crazy sort orders, most notably "specification" and "tag".
Both of these take the alphabetically first linked spec or tag for each
bug, and sort alphabetically based on that -- not exactly obvious,
performant or useful.

So I'd like to drop them. "specification" doesn't seem to be accessible
from the UI at all, but "tag" has a sort lozenge. I seem to recall that
the lozenges also exist as a bit of a legend for the table content, so
perhaps dropping the tag lozenge is not ideal. What do people think?


Relatedly, various other orders will continue to be slow on large sets
of bugs. Some are never going to be fast without further denormalisation
and big new indices that probably aren't worth it (eg. reporter,
assignee, milestone_name, targetname), and others are sufficiently rare
or unuseful that it's probably not worth optimising for them
(number_of_duplicates, message_count, title, maybe users_affected_count,
latest_patch_uploaded come to mind).

Given the timeouts-are-critical policy, it seems less than ideal to
leave these slow sorts to time out. We could perhaps limit their usage
to smaller sets of bugs, but that is awkward and poses challenges of its
own. Ideas?

William

Attachment: signature.asc
Description: OpenPGP digital signature