You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What kind of graph storage and algorithms does Apache Age use? Is it purely backed by PostgreSQL tables, or is there an in-memory representation? How hard would it be to extend it to have a DAG-optimized representation, with corresponding query optimizations (and data limitations)?
So far I started writing an FDW that just keeps the complete graph in memory and does the absolute minimum queries we need, but there's the question of storage and transaction support which bothers me. I think ideally it could be an extension, using PostgreSQL tables as storage, but maintaining an optimized in-memory representation (stealing it and the algorithms from Git itself, perhaps). However, an FDW is proving challenging already to me as a newbie, so I'd like to see how hard it could be to modify an existing extension instead :D
Thank you!
(reposting from r/apacheage, since I got no response there)
The text was updated successfully, but these errors were encountered:
@spbnick The graph is stored in tables. However, for some queries [VLE specifically] there is an in-memory data structure that represents the graph allowing graph algorithms easier transversal.
Thank you @jrgemignani, I'll consider looking at that structure. However, so far my attempts at using Apache AGE with my dataset were mostly a failure :( So for now I'm building my own FDW.
I'm looking for a solution to store and query a revision history DAG for the Linux kernel, including the subtrees and patches on the maillist, within PostgreSQL. Context: https://archive.fosdem.org/2023/schedule/event/graph_case_for_dag/
What kind of graph storage and algorithms does Apache Age use? Is it purely backed by PostgreSQL tables, or is there an in-memory representation? How hard would it be to extend it to have a DAG-optimized representation, with corresponding query optimizations (and data limitations)?
So far I started writing an FDW that just keeps the complete graph in memory and does the absolute minimum queries we need, but there's the question of storage and transaction support which bothers me. I think ideally it could be an extension, using PostgreSQL tables as storage, but maintaining an optimized in-memory representation (stealing it and the algorithms from Git itself, perhaps). However, an FDW is proving challenging already to me as a newbie, so I'd like to see how hard it could be to modify an existing extension instead :D
Thank you!
(reposting from r/apacheage, since I got no response there)
The text was updated successfully, but these errors were encountered: