search for -FOO alone causes a timeout and might be better as a substring search

This timeout happens because tsearch2 interprets '-de' as !'de' (meaning any person/team whose name/email doesn't contain the string 'de' will match). That's why it takes so long and times out -- there are nearly 2 billion people/teams which match that query for '-de'.

It may be possible to escape that '-' so that it's not interpreted as '!', but I don't know how. Any ideas, Stuart?

I don't think it should be escaped, because a not operator is useful for searches in general, the "-term" syntax is more familiar to anyone who's used Google, and escaping it wouldn't stop exactly the same error from occurring with "!de" anyway.

However, it would make sense to disallow searching with a not operator (regardless of syntax) unless the search string also contains at least one positive term. So <https://launchpad.net/people/?name=-de&searchfor=all> would return an error telling you to add more terms, but <https://launchpad.net/people/?name=foo+-de&searchfor=all> would work.

Further, it probably doesn't make sense to allow not operators in the popup search (hence bug 123898).

Hi Stuart,

you set this bug to incomplete but have not requested any further information. What's missing?

If this bug is about making search timeouts produce a nicer error message, we can do that but it doesn't have much to do with the syntax. Ideally we should try to detect a query that will take too long before executing it (checking the query plan for instance is a good indicator). Lots of call sites make this problematic. We also may need to create a custom timeout screen for searches rather than the OOPS.

I don't think we want to change the search syntax to band aid one particular way of triggering the problem, making our already undocumented search syntax even more surprising.

Eventually we want person fields to have an autocomplete menu, rather than a skody iframe. Autocomplete operates on strict substrings, which is a fundamentally different syntax from a full-blown search. For example, typing -it.org into Firefox's address field should, and does, offer any URLs you have visited on ubuntu-it.org. Nobody expects it to offer every URL in their browser history except for those on it.org, as that would almost always be useless. The same would apply to a person auto-complete field in Launchpad: someone entering -de pretty obviously wouldn't want to see a menu of everyone in Launchpad except those called "de".

So the question is whether it's better for the iframe search to work the way a full-blown person search works now, or the way the autocomplete search eventually will work. I think the latter would be better, first because it would fix this timeout, and second because it would make the autocomplete easier to implement later. Whatever solution we decide, though, the actual problem is fully described and therefore not Incomplete.

High as per zero-oops policy.

I wonder if the main query will complete if the count(*) doesn't. Perhaps we could make record set .count() set a temporary timeout to cancel queries taking more than (say) 1 second.

Repacking our indices and other improvements have made this work. Win.