The query gets auto-parameterised, and planned to work on arbitrary user-supplied lists for the IN clause. This makes the query plan cache effective even when people parameterise with client-side string concatenation.
The same auto-parameterisation happens to the OR based query, except there the cardinality is given syntactically, rather than via a parameter. Thus you get a different plan. -- Chris Vest System Engineer, Neo Technology > On 21 May 2017, at 21.34, Sun Yuhan <[email protected]> wrote: > > I have tried to profile a query like " profile match (n) where id(n) in [0, > 1] return n". No matter whatever the size of the list, the estimation for the > number of rows is 25. This is ridiculous. The estimation should be a number > based on size of the list. > > When I try another way of writing the query: " profile match (n) where id(n) > = 0 or id(n) = 1 return n", the estimation can vary according to how many ids > the query requires. > > So I think the optimizer should be fixed for the first case "[id1, id2, id3, > ...]". > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
