Postgres: The Graph Database You Didn't Know You Had

Re:Postgres: The Graph Database You Didn't Know You Had by switchbak on Friday March 31, 2023 @12:11PM (#35389263)

"you can't exit the search early when a condition is met" - I have a DAG traversal written in a recursive CTE, and I can bail early out just fine when my traversal predicates no longer match. Not sure why I'd have to do that outside the (recursive part of the) CTE?

Obviously maintaining a flattened version is going to perform better in queries, but you're trading maintenance (write) time for query time. Or materialization time if you decide to do it lazily.

[ Parent | on HN ]

Re:Postgres: The Graph Database You Didn't Know You Had by ellisv on Friday March 31, 2023 @01:21PM (#35390135)

If you have an edge list like:

A->B

A->D

B->C

C->D

Postgres will walk both paths from A to D in the recursive CTE and then you can filter them afterwards to keep only the shortest.

You can use aggregate functions within the recursive CTE, so you can’t GROUP BY your starting node and stop once you find the first path. There isn’t a way to compare across multiple paths or iterations of the for-loop.

[ Parent | on HN ]

Re:Postgres: The Graph Database You Didn't Know You Had by FleaFlicker99 on Friday March 31, 2023 @01:41PM (#35390450)

Ok but that's a little different than saying you can't cut the traversal short.

If I'm traversing ancestors (let's say) until I find one that doesn't satisfy a condition, it'll bail out then. I get that this doesn't serve all uses cases, but it isn't a small thing either.

[ Parent | on HN ]