The way the query that the user's input is built into a query submitted to Elasticsearch could be improved. This has been known for some time. However, it is opportune (and somewhat necessary) to do this during our work on cross-project searching to improve performance. This task is to track that work. We assume we will want to do this after the load test documented in T149740.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | debt | T145918 [EPIC] Backend: cross-wiki search results functionality | |||
| Resolved | EBernhardson | T149740 Run load tests of cross-project searching to verify its stability | |||
| Resolved | EBernhardson | T149741 Improve how search queries are built for cross-wiki searches to allow for better filtering |
Event Timeline
Comment Actions
@dcausse Any concrete ideas on what we would be doing here? If my memory serves part of the initial intention here was to stop re-building the same query N times, where N = number of sister wikis. My refactor of interwiki search partially addressed that (the query builder is now only run once for the main query, and once for all sister wikis), although Searcher::buildSearch is still run for each wiki.
Comment Actions
Is perf the sole concern here?
I'm fine running buildSearch multiple times and I think that your optimization at mw level is already sufficient. I don't think that optimizing this part is worthwhile (e.g. running buildSearch only once).
If we have perf issues I'd prefer to build a separate and simpler query for sister projects, possibly by reusing the SimpleMatch query builder with a smaller set of fields.
If perf is not the sole concern I'd say that the query highly depends on what we display, imho the current behavior is sometimes misleading, we search for everything but only display the Title. The user should have a small indication on why this page matched the query (text snippet).
Comment Actions
punting to be re-considered if necessary after running some tests with interwiki search.
Comment Actions
This would allow us to more easily configure what kind of queries we run on sister wikis, which may be important if we don't get enough queries.
Comment Actions
We can work on this after the A/B tests for sister project search results (T145917), as needed.
Comment Actions
After various parsing work these queries are now fairly configurable, and source their configuration from the host wiki. Additionally the new (since this ticket) interwiki results display includes snippets to tell users why the title matched.