graphql
graphql copied to clipboard
neo4j
Index support
@neo4j/graphql currently supports the creation of full-text indexes, but not B-tree indexes, which can be used to improve read performance. This should probably be specified by a directive on the object type which allows the specification of multiple fields for composite indexes.
given that b-tree indexes are deprecated will you consider having support for TEXT indexes? Another idea related to indexes is to include them (when queried for in a where clause for example) in the USING statement. This could cut down on query plan time and produce better query plans.
Whilst B-tree indexes are deprecated, they are being immediately replaced by range indexes, and the standard CREATE INDEX command will now create range indexes instead of B-tree indexes (https://neo4j.com/docs/cypher-manual/current/indexes-for-search-performance/#indexes-future-indexes).
Interesting suggestion regarding using USING, thanks for the suggestion and we'll keep it on board!
just figured i'd add in again how useful adding Query Hints could be to the queries, I have a graph with quite a few relationships, and when I have a graphql query that uses properties of nodes and traverses relationships I often get very poor planning. I took the resulting cypher and profiled it and had 10's of millions of db hits. When I added the USING Index ... on the single node property I was using in the query (and which had an index) I then only had 1100 dbhits. This was on neo4j 4.4.9, i'll test with a later version, but I was disappointed to see the query planning make such a poor plan. In the plan it was opening every single possible relationship, leading to tons of db hits as opposed to filtering by node first and then expanding the relationships.
Update, I had a property on all nodes which was always the same and was indexed, as soon as i removed that index the planner must have switched to using a different index and now everything is fast. Query Hints could still be a very nice addition though.