Query tuning - Reducing cardinality chapter weird?

[tard_gabriel]

Hello there

In the Improved query using full-text schema index example description we can read "The solution to this is the remove the labels from the MATCH statement".

So this suppose that there was a MATCH statement in the previous example that we want to improve. But in the previous example:

Example: Using the full-text schema index

There is no MATCH statement, so is it because I'm tired and I don't get it or is there something missing here. And the sentence:

We see that the execution plan is doing a NodeByLabelScan

Actually, I don't see that in the provided query plan example.

And the "improved" example is even worst than the first one in terms of performance.

Thanks

[sameer_gijare14]

Hi Tard

If the database has indexes, you should strive to ensure that execution plans use them. Ideally, you want indexes that have values with the lowest selectivity. The query planner will always choose to use indexes with low selectivity values.

By default, the execution plan will use a single index.

Here is a query that uses an index $actor1 is "Tom Cruise" and $actor2 is "Kevin Bacon".

Cypher

Copy to Clipboard

PROFILE
MATCH p = (p1:Person)-[:ACTED_IN*4]-(p2:Person)
WHERE p1.name = $actor1
  AND p2.name = $actor2
RETURN [n IN nodes(p) | coalesce(n.title, n.name)]

It finds all paths that represent 4 hops between two actors where $actor1 is "Tom Cruise" and $actor2 is "Kevin Bacon". Then it returns a list of names or titles for the nodes in the paths found.

[elaine_rosenber]

@tard.gabriel there are some very subtle improvements in that query. If you were to include the labels in the node specification, you would see a poorer performing query.

The improvement in the query is comparing the node by label scan query.

I agree that we should improve what query we are referring to as the improved query.

Elaine