[GitHub] incubator-madlib issue #78: Graph: SSSP

2016-12-19 Thread orhankislal
Github user orhankislal commented on the issue: https://github.com/apache/incubator-madlib/pull/78 Yes that is the idea. I don't bother checking an edge unless its source vertex has been updated in the last pass. --- If your project is set up for it, you can reply to this email and

[GitHub] incubator-madlib issue #78: Graph: SSSP

2016-12-16 Thread decibel
Github user decibel commented on the issue: https://github.com/apache/incubator-madlib/pull/78 Ok, I think I finally figured out what's going on here... you're keeping a table of every possible destination, as well as the minimum cost to that destination seen so far. The rest of this

[GitHub] incubator-madlib issue #78: Graph: SSSP

2016-12-16 Thread decibel
Github user decibel commented on the issue: https://github.com/apache/incubator-madlib/pull/78 You should really add that as a comment to the code. It's much clearer than reading the code itself. And yes, it definitely helped me. I now realize what's been bugging me about

[GitHub] incubator-madlib issue #78: Graph: SSSP

2016-12-16 Thread orhankislal
Github user orhankislal commented on the issue: https://github.com/apache/incubator-madlib/pull/78 @decibel I posted a pseudocode in the JIRA. Please let me know if that clarifies why I needed the multilayered sql code. --- If your project is set up for it, you can reply to this

[GitHub] incubator-madlib issue #78: Graph: SSSP

2016-12-15 Thread decibel
Github user decibel commented on the issue: https://github.com/apache/incubator-madlib/pull/78 Sounds good. I'd still like to see pseudocode as part of the documentation, because I don't think all these steps are necessary. --- If your project is set up for it, you can reply to

[GitHub] incubator-madlib issue #78: Graph: SSSP

2016-12-14 Thread orhankislal
Github user orhankislal commented on the issue: https://github.com/apache/incubator-madlib/pull/78 Here is what I am thinking: We should create a new JIRA for SSSP Phase 2 to explore plpgsql implementation with an array to replace `toupdate` and `message` tables. I am not sure how

[GitHub] incubator-madlib issue #78: Graph: SSSP

2016-12-13 Thread orhankislal
Github user orhankislal commented on the issue: https://github.com/apache/incubator-madlib/pull/78 Unfortunately, GPDB does not support RECURSIVE option in WITH clause. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If

[GitHub] incubator-madlib issue #78: Graph: SSSP

2016-12-12 Thread orhankislal
Github user orhankislal commented on the issue: https://github.com/apache/incubator-madlib/pull/78 I'll put the pseudocode in the JIRA (https://issues.apache.org/jira/browse/MADLIB-992) --- If your project is set up for it, you can reply to this email and have your reply appear on

[GitHub] incubator-madlib issue #78: Graph: SSSP

2016-12-12 Thread decibel
Github user decibel commented on the issue: https://github.com/apache/incubator-madlib/pull/78 Yeah, the 1GB limit is certainly a consideration. Using int4's for everything, a composite of (srt, dest, weight) would be 13-16 bytes (3 * int4 = 12 + varlena and maybe alignment). With

[GitHub] incubator-madlib issue #78: Graph: SSSP

2016-12-07 Thread orhankislal
Github user orhankislal commented on the issue: https://github.com/apache/incubator-madlib/pull/78 Hi @decibel, I was wondering if you would be interested in taking a look at this PR. I would appreciate your comments/suggestions. --- If your project is set up for it, you can reply