Graph processing can create substantial amount of intermediate data if it is done in typical join implementation fashion (nested loops or hash join). So it may appear that graph processing needs a tailored approach.
But what can help graph algorithms can help SQL query execution as well and vice versa, see the link above.
For example, TPC-DS contains queries that (indirectly) joins same tables multiple times (query 4, for example). This is, basically, a kind of centrality metric computation for a graph represented by the tables.
No, it is not.
[1] https://en.wikipedia.org/wiki/Worst-case_optimal_join_algori...
Graph processing can create substantial amount of intermediate data if it is done in typical join implementation fashion (nested loops or hash join). So it may appear that graph processing needs a tailored approach.
But what can help graph algorithms can help SQL query execution as well and vice versa, see the link above.
For example, TPC-DS contains queries that (indirectly) joins same tables multiple times (query 4, for example). This is, basically, a kind of centrality metric computation for a graph represented by the tables.