pdpotter commented on issue #45:
URL: https://github.com/apache/incubator-age/issues/45#issuecomment-1121484835
It looks like I have been a bit too enthusiastic in my previous comments.
### Property constraints
When using GIN indices on properties and creating relations using these
indices, I didn't check if the relations where actually added. Unfortunately,
they where not.
After adding a GIN index and adding enough vertices so the index is used, a
match query doesn't return any results. E.g.,
```
SELECT * FROM cypher('test_graph', $$CREATE (p:person {id: 1}) return p$$)
as (p agtype);
SELECT * FROM cypher('test_graph', $$CREATE (p:person {id: 2}) return p$$)
as (p agtype);
...
SELECT * FROM cypher('test_graph', $$CREATE (p:person {id: 500}) return p$$)
as (p agtype);
CREATE INDEX person__properties ON test_graph.person USING GIN (properties);
```
A match query using property constraints returns 0 results.
```
SELECT * FROM cypher('test_graph', $$MATCH (p:person {id: 1}) return p$$) as
(p agtype);
p
---
(0 rows)
```
Query plan:
```
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on person p (cost=12.01..16.03 rows=1 width=32) (actual
time=0.026..0.027 rows=0 loops=1)
Recheck Cond: (properties @> agtype_build_map('id'::text, '1'::agtype))
-> Bitmap Index Scan on person__properties (cost=0.00..12.01 rows=1
width=0) (actual time=0.024..0.024 rows=0 loops=1)
Index Cond: (properties @> agtype_build_map('id'::text,
'1'::agtype))
Planning Time: 0.158 ms
Execution Time: 0.075 ms
(6 rows)
```
### Where clause
When using the where clause, it is not the GIN index that is being used, but
the unique index that was added to prevent duplicate entries by executing
```
CREATE UNIQUE INDEX person__id ON test_graph.person (properties);
```
The WHERE clause does give a correct result:
```
SELECT * FROM cypher('test_graph', $$MATCH (p:person) WHERE p.id = 1) return
p$$) as (p agtype);
p
-----------------------------------------------------------------------------
{"id": 844424930131969, "label": "person", "properties": {"id": 1}}::vertex
(1 row)
```
Query plan:
```
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using person__id on person p (cost=0.27..8.30 rows=1 width=32)
(actual time=0.063..0.065 rows=1 loops=1)
Index Cond: (agtype_access_operator(VARIADIC ARRAY[properties,
'"id"'::agtype]) = '1'::agtype)
Planning Time: 0.190 ms
Execution Time: 0.103 ms
(4 rows)
```
When using the WHERE clause for creating relations, the performance
decreases when adding a lot of relations (when adding relations in batches of
5000, the first batch achieves ~5000 it/s, while the ninth batch achieves ~500
it/s) using something similar to
```
SELECT * FROM cypher('graph_name', $$
MATCH (d:LabelA ), (r:LabelB)
WHERE d.id = 1 AND r.id = 2
CREATE (d)-[:Relation {prop: 'value'}]->(r)
$$) as (a agtype)
```
### Test suite
When having a new look at the tests
(https://github.com/apache/incubator-age/blob/master/regress/expected/index.out#L299-L336)
to check if I was making mistakes, I found out some of the index related tests
might have some issues:
* Are the indices being used with a limited amount of vertices?
* The query at
https://github.com/apache/incubator-age/blob/master/regress/expected/index.out#L304
returns 0 results, which is expected, but it might be useful to check if
results are returned for other queries (e.g., `MATCH (c:City {country_code:
"US"})`. Queries
https://github.com/apache/incubator-age/blob/master/regress/expected/index.out#L318
and
https://github.com/apache/incubator-age/blob/master/regress/expected/index.out#L330
are similar cases.
* There are errors on lines
https://github.com/apache/incubator-age/blob/master/regress/expected/index.out#L314
and
https://github.com/apache/incubator-age/blob/master/regress/expected/index.out#L335
Thank you so much for making Apache AGE better and better with each commit.
I'm sorry if I caused any confusion with my previous comments.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
