Impacted versions:
8.0 and so on

Steps to reproduce:
create a many2many field in product.product such as:
`'company_ids':fields.many2many('res.company','res_company_product_rel','partner_id','company_ids',string=u'multi company''),`
and add a ir.rule for product.product with  domain such as
`['|',('company_id','=',False),('company_ids','in',[c.id for c in user.company_ids])]`
and import 10 thousand product.
then login with normal user(not super) and open the product.produt list view
it taks several minus to open

Current behavior:
when I search product.product
all product id have been hard coded in the sql 
lead to low performance.

Expected behavior:
not hard code produt id

Video/Screenshot link (optional):
in the sql below 10 thousand product id have been hard code in the position %s
AND ("product_product__product_tmpl_id"."company_id" IS NULL   OR  ("product_product"."id" in (%s)))

(not <term1>) and (<term2> or <term3>)
The second level of syntax deals with the term representation. A term
is a triple of the form (left, operator, right). That is, a term uses
an infix notation, and the available operators, and possible left and
right operands differ with those of the previous level. Here is a
possible term::
    ('company_id.name', '=', 'OpenERP')
The left and right operand don't have the same possible values. The
left operand is field name (related to the model for which the domain
applies).  Actually, the field name can use the dot-notation to
traverse relationships.  The right operand is a Python value whose
type should match the used operator and field type. In the above
example, a string is used because the name field of a company has type
string, and because we use the '=' operator. When appropriate, a 'in'
operator can be used, and thus the right operand should be a list.
Note: the non-uniform syntax could have been more uniform, but this
would hide an important limitation of the domain syntax. Say that the
term representation was ['=', 'company_id.name', 'OpenERP']. Used in a
complete domain, this would look like::
    ['!', ['=', 'company_id.name', 'OpenERP']]
and you would be tempted to believe something like this would be
possible::
    ['!', ['=', 'company_id.name', ['&', ..., ...]]]
That is, a domain could be a valid operand. But this is not the
case. A domain is really limited to a two-level nature, and can not
take a recursive form: a domain is not a valid second-level operand.
Unaccent - Accent-insensitive search
OpenERP will use the SQL function 'unaccent' when available for the
'ilike' and 'not ilike' operators, and enabled in the configuration.
Normally the 'unaccent' function is obtained from `the PostgreSQL