Tuesday, December 16, 2025
2 changes · 19.0
Enhancements to existing features
Product searches now return results much faster when looking across product names, references, and related product information. This improves responsiveness for users working with large product catalogs, especially during sales, purchasing, or inventory workflows.
Original PR description
When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product…
When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product or product_template) as postgresql uses a Bitmap OR when everything is properly indexed.
When leaves are on multiple tables however postgresql has to plan a Seq Scan. For instance, let's take a simple domain on product.product of the form `['|', ('name', 'ilike', 'test'), ('default_code', 'ilike', 'test')]`. Because `name` is an inherited field via `product_tmpl_id`, the resulting query has the where clause `join_table.name ilike %s OR product_product.default_code ilike %s` with `join_table` the table you get after joining product_product and product_template. Since it's an `OR` condition, postgresql does not know in advance whether a given row will pass this condition. There's no way to filter the tables before the join. The condition moves therefore to a `Join Filter` node and postgresql has to scan the whole join table to fetch the correct tuples.
Same thing when there's a subquery. In case of a where clause `cond OR cond OR subquery`, postgresql does not know in advance whether or not a given row is gonna pass the subquery condition. So it has to scan the whole table.
In both cases this becomes a bottlneck when the number of products increaases. This commit introduces the use of `UNION ALL` instead of `OR`. There's one SubPlan for each individual table in the domain. The results are then appended to get the final products matching the conditions. Thanks to each table having its own SubPlan postgresql can now properly hit indexes for each table, greatly improving the performances.
#### speedup
In a database with 2.5M product_product, the name_search on product with a partner_id in the context and the ilike operator goes from 8s -> 5ms.
In another database with 500k product_template, the name_search on template with a partner_id in the context and the ilike operator goes from 1.8s -> 5ms.
opw-4921944
opw-5103287
opw-5049054
opw-5256691
opw-5221753
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238901
Forward-Port-Of: odoo/odoo#229275Resolved issues and error corrections
This update resolves a critical issue where the Odoo Report Editor was crashing due to incorrect translation processing within the report's HTML. By disabling translation specifically for the report's iframe content, the problem is fixed, ensuring reports save correctly and preventing future crashes.
Original PR description
Before this commit, when google translate was active on the current ReportEditor, it produced wrong data to save, and ultimately crashes. After this commit, since we disable the translation on the whole HTML element inside the iframe (that is only for the edited report), there is no error any more opw-5122924 Forward-Port-Of: odoo/enterprise#97019