all_sm is referenced by two branches of the outer UNION, so PostgreSQL materializes it (a CTE used more than once is an optimization fence). Every query on report_stock_quantity therefore builds the forecast for all products/warehouses first and filters afterwards, so predicates like product_id can't reach the stock_move scan.

This hurts single-product lookups such as _read_group() in mrp_report_bom_structure._get_stock_availability(), called repeatedly per component while rendering a BoM report: each call does a full stock_move scan plus two sorts that spill to disk.

Marking all_sm NOT MATERIALIZED lets the planner inline it and push the product_id/warehouse_id filter down to an index scan, removing the full scan, the GENERATE_SERIES expansion and the on-disk sorts. warehouse_cte stays materialized (small and cheap).

Query generated from the _read_group:
```SQL
SELECT MIN("report_stock_quantity"."date")
FROM "report_stock_quantity"
WHERE (
        (
            (
                (
                    ("report_stock_quantity"."state" = 'forecast')
                    AND ("report_stock_quantity"."date" >= '2026-07-08')
                )
                AND ("report_stock_quantity"."product_id" = 15743)
            )
            AND ("report_stock_quantity"."product_qty" >= 1.0)
        )
        AND ("report_stock_quantity"."warehouse_id" = 4)
    )
    AND ("report_stock_quantity"."company_id" IN (1))
```

Before:
800 ms by _read_group in _get_stock_availability().
For opening a BoM overview with hundred of components takes 17 sec.

After:
25 ms by _read_group in _get_stock_availability().
Same BoM overview drops to 3 sec to open.

cc @Aurelienvd 



I can send you EXPLAIN ANALYZE, but I prefer to not putting them here to avoid data leakage.

Forward-Port-Of: odoo/odoo#275022