Description:
When searching with a domain that contains a relational field whos
comodel is `res.users`, with a *pathological* domain of `not ilike`
`'some_string'`, the ORM will call a `_name_search` on `res.users`
with no limit to resolve the leaf when calling `_where_calc`.
The current implementation in the `web` module overrides the
`_name_search` to implement a spec to propose the current user as a
first suggestion, but to do that it first execute the query
(the list conversion), and then manipulates the list of ids to insert
the current user first. (1c2ce8c213)
On large databases with many `res.users`, where the condition matches all
users besides 1, this is a probably Seq.Scan on the `res_users`
table. Then this gigantic list of `ids` will be injected by the ORM
into the main query to satisfy the original domain. This incurs not
only bandwidth costs, but also usually leads to bad plans, ending up
most likely into a Seq.Scan on the original table.
The worse of it, in the case of a `web_search_read`, there is a
`search_count`, so this whole fiasco is repeated once more.
The nail in the coffin, is that the result isn't even needed, when
resolving a comodel's `_name_search`, we care about the subset, the
internal order is irrelevant.
Solution:
The ORM calls the `_name_search` without a limit, while in general the
`name_search` is called with a limit from the front-end, therefor we
can use it as a discriminant -> If no limit, don't suggest `uid` first.
Affected versions:
saas-16.3 -> master (saas-17.2)
Reference:
task-3610657
closesodoo/odoo#154149
X-original-commit: 83aa46a4ab88c0226b1aa1dc36671d3208a0835a
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Victor Piryns (pivi)
9117487844
