Push Evaluation Strategy performance issue

[peterjohnlawrence]

If I configure a repository with Push, the performance of the SPARQL query is extremely slow and might not return within timeout.
If I create the same repository but with Push disabled the performance is reasonable.

Background:

• The SPARQL query is very complex (paths, sub-queries etc): would this impact the Push strategy?
• I have Halyard running in a single node configuration: would this also impact use of the Push strategy?
• HBase1.2.6/Hadoop2.7.4/Halyard2.5

[asotona]

Push strategy is beneficial when: - there is a latency in communication with HBase region servers (network multi-node cluster installation) - dataset regions are balanced and equally distributed across multiple region servers so parallel asynchronous communication does not create hot spots (usage of pre-split and control over HBase traffic) - join optimizer in Push strategy requires stats computation for its optimal work (outdated stats are still much better than none) - some of the complex patterns are better than others (for example to use filtering rather than minus or organize subqueries so they can be chained) - query profiler can be used to analyze the reason of long-running queries if all the above failed Adam

…

18. 7. 2020 v 11:18, Lawrence ***@***.***>:  If I configure a repository with Push, the performance of the SPARQL query is extremely slow and might not return within timeout. If I create the same repository but with Push disabled the performance is reasonable. Background: The SPARQL query is very complex (paths, sub-queries etc): would this impact the Push strategy? I have Halyard running in a single node configuration: would this also impact use of the Push strategy? HBase1.2.6/Hadoop2.7.4/Halyard2.5 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.