jrgemignani commented on issue #562: URL: https://github.com/apache/age/issues/562#issuecomment-1693774266
@vladiksun It is a bit complicated how these components integrate together and how PostgreSQL may decide how to deal with them. Yes, the WHERE clause can also be part of other clauses, but my examples here are referring to MATCH specifically. As mentioned above, the WHERE clause works on some **expression** passed to it from somewhere. The MATCH clause works on a **path** and the **property constraints** provided in the path. These two are different and an index for one likely won't work for the other. All of the examples I have seen so far suggest that they won't. (1) The WHERE clause is added to the **jointree** as a **FromExpr** **AND**ed with the clause that it is part of, MATCH in these cases. MATCH's **property constraints** are also added to the **jointree** as a **FromExpr**. We provide this new query tree back to PostgreSQL where the planner/optimizer is basically free to do what ever it likes. So, it is not surprising to see them mixed together since they are **AND**ed together. It is attempting to optimize the query. Hopefully this helps (1) When the indexes are matched to their clauses, the match routines looks to match their components. A **contains** won't match to an **access** operator because they are two different functions with different arguments. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@age.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
