41–50 of 77 posts
Earlier quoted context omitted.
Did you try dgraph? For our use cases it won over neo4j. Didn’t try redisgraph.
We benchmarked all 3; redisgraph was fastest by far.
This is a great project, but last time I checked it was lacking a lot of CYPHER features and wasn’t moving very fast forward. But I’m hoping it will catch up to the point it will become useful.
Interesting. What are some good extensions for pg? I have only used UUID and postgis.
If you used "uuid-ossp" to get uuid_generate_v4(), then this is no longer necessary since Postgres 13 as there is now a built-in gen_random_uuid()
Earlier quoted context omitted.
We benchmarked all 3; redisgraph was fastest by far.
Ok, but on what metrics? I don't mean I disbelieve, I would just like to know that it was fastest on the things I might care about.
Earlier quoted context omitted.
Did you try dgraph? For our use cases it won over neo4j. Didn’t try redisgraph.
We benchmarked all 3; redisgraph was fastest by far.
This is written in C. I wonder how common it is to write PG extensions in safer langugaes and what would be the most suitable. I'm somewhat wary of using nontrivial C extensions, having seen so many of them sometimes seg fault the backend (eg PostGIS). There seem to be PG backend crashes described in this projects issues as well.
PG has a special memory manage rule, named MemoryContext. All memory allocated in a context will disappear when it leaves that context. this means that you can safely not free memory, or your memory will be freed in unexpected places. this is a big conflict with the way rust manages memory. write extension in rust won't improve it much. And in PG, there is a special method to create a process, creating threads is not…
Naive question from a non-c user, setjmp/longjmp just manipulate the stack and since each thread has its own execution stack, that should be completely safe ISTM - so why is it unsafe/impossible? I'm missing something.
"Apache AGE is currently being developed for the PostgreSQL 12 release" Well sorry, we have PostgreSQL 15 already.
I create a DAG using recursive sql. I assume that saving data in a graph and querying the graph with a native graph language would be faster. Has anyone benchmarked performance differences between the two?
Most examples of Recursive SQL I've seen will only involve nodes on exactly one Table an with exactly one kind of a relationship/edge (for example a tree with "parent" edges). Graph DBs allow you to relate multiple different types of nodes using multiple kinds of edges. The edges can have queryable attributes like an intermediary table in a many-to-many relationship. And all of that is still indexed efficiently.