Short answer:
Full-Text search + sorting has degenerate cases, and they become more likely when you're combining search criterias with filters (/saving searches) instead of using the search box directly.
It sounds like you're generating the title field programmatically (hence the "title:SpecialUpload" criteria) -- You could programmatically add a tag to the cases you wish to filter for (tag:SpecialUpload) and then filter based on the tag (a non-full-text operation) rather than the title (a full-text operation) in order to get much faster results.
Long answer:
The behavior you're seeing is most likely caused by combinations of the following factors:
- Full-text searches (such as title:) are much slower than other search/filter operations
- Full-text searches combined with a sort order can lead to a degenerate case, but even when they don't will be strictly slower than non-ordered full-text search operations
- Filters tend to have sort orders, whereas searches you type directly into the search bar are only sorted if you specify a sort order (...otherwise they sort by a relevance metric)
There are two types of operations which FogBugz will perform when you run a filter or a search:
- Result filtering based on values in the database
- Full-Text search using Lucene
Filters, filters with a search component, and searches entered into the search field all make their way to the same "query parser". This parser extracts the full-text components from the query, runs them against Lucene, and then combines the Lucene results with the database column filtering requested by the query.
For example, searching for Jude status:active will retrieve full-text matches of my name, from Lucene, and then join that result set with the items from the database which match the criteria of status:active.
I'm leaving out a few steps here (like permissions checks), but that's the gist of it.
In your case,
project:Beta openedby:beta title:SpecialUpload
The Project and OpenedBy axes are filtering using the database, while the title axis is filtering against lucene. Because we incur the cost of interacting with the full-text search engine, this query is strictly slower than
project:Beta openedby:beta
which doesn't interact with Lucene at all.
Searches embedded in filters are slightly more advanced: the query parser combines the filter logic with the search logic in order to put together it's best effort approximation of the desired query. Since the search component can be arbitrary (and even contradict the filter component), it's possible to create some interesting results here. Regardless, it tends to be the case that queries created by combining filters with searches (rather than performing the 'equivalent' search using the search box) actualy have some additional implicit filtering criteria (such as sort order.)
e.g.,
a filter with a specific sort order (almost all filters have this) plus a full-text search component is going to be strictly slower than that same filter without the sort, which in turn is going to be strictly slower than that same filter without the full-text search.
I would guess that the multi-tiered performance profiles you're seeing are:
- Non-full-text filters/search (regardless of sort order)
- Full-text search (no sort)
- Filter with full-text search (same as #2, but with additional filtering overhead)
- Filter with sort ordering and full-text search
