-
-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance Degradation on Simple Query with ArcadeDB Embedded Version 24.5.1 #1730
Comments
Do you have an index on |
The index is used, but 02% of the time is spent on edge traversing. How many edges do you have between vertices? Is E_36 an outgoing vertex from V_6 or are you interested in both incoming and outgoing? Also, can you run this SQL query? select expand( both("E_36") ) from V_6 where id = 647 |
The math on the explanation doesn't add up for the 1,174ms of the query. Is there any way we can look into the database? Is it possible that you previously created and deleted many edges from that vertex? |
This is exactly the issue we're trying to track down but haven't been able to identify the root cause yet. Regarding the created and deleted edges, our system is built on a Spring Boot application that uses an embedded ArcadeDB. Whenever users create or delete relations in our system, these changes are saved directly to ArcadeDB. However, we haven't noticed any specific patterns or issues related to previously deleted edges causing problems. |
If you can't send me your database zipped to |
I've just sent an email to your support team. As this is a customer environment, we can't provide direct access to the database, but we're happy to arrange a session to investigate further. |
ArcadeDB Version: 24.5.1 (Embedded)
Operating System: Windows
JDK Version: 11
Nodes: 8357
Edges: 13557
Problem Description:
I am experiencing significant performance issues when running a simple query on ArcadeDB embedded version 24.5.1. The query in question is as follows:
MATCH (n:V_6)-[e:E_36]-(p:V_8) WHERE n.id = 647 RETURN n, p LIMIT 1
This query takes approximately 4 seconds to retrieve a result, which seems excessive given the dataset size (8357 nodes and 13557 edges). I would expect much faster execution times for a query of this simplicity.
I have searched through the documentation but could not find any clear information regarding performance tuning or optimization guidelines for embedded use cases. This issue occurs consistently with the same query structure and dataset size.
Any suggestions for improving query performance, configuration changes, or indexing strategies would be greatly appreciated.
The text was updated successfully, but these errors were encountered: