Details

    • Type: Bug
    • Status: Duplicate
    • Priority: Medium
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      The latest BLZG-533 benchmarks (https://docs.google.com/spreadsheets/d/1MFF3kQmzQv7LzBFjbNX7bhc1eLgCVPQH0vQA6SxeHuQ/edit#gid=910656385) indicate a different result cardinality for one of the govtrack queries. We need to understand what the correct answer is and why the behavior changed, possibly include a fix.

        Activity

        Hide
        michaelschmidt michaelschmidt added a comment -

        First observation: this seems not to be related to the changes in BLZG-533, already see these numbers for older RCs, such as the master from July 13 (after the jetty upgrade).

        Show
        michaelschmidt michaelschmidt added a comment - First observation: this seems not to be related to the changes in BLZG-533 , already see these numbers for older RCs, such as the master from July 13 (after the jetty upgrade).
        Hide
        michaelschmidt michaelschmidt added a comment -

        Having looked at the query again, I believe that neither 20601 nor 20641 are actually the desired result, but the query should yield the same number of results than the other query0021* variants, namely 20681. The 20641 results delivered by the latest branch are actually closer to the truth, they contain cases where ?_var2 is not bound. This came in at some point by a fix from Alexandre (grouping also supports grouping over null & error values -> the difference actually is that the 20641 results now also contain such cases).

        I also traced it down to a minimal failing query:

        PREFIX p1: <http://www.rdfabout.com/rdf/schema/usgovt/>
        PREFIX p2: <http://www.rdfabout.com/rdf/schema/vote/>
        PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
        PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
        
        SELECT (COUNT(*) AS ?cnt) WHERE {
        
            ?_var10 p2:votedBy <http://www.rdfabout.com/rdf/usgov/congress/people/C000877>. 
            ?_var10 rdfs:label ?_var2.
            hint:Prior hint:hashJoin "true" .
        } 
        

        Funny enough, searching for this problem in JIRA, this is exactly the query I came up with a while ago: https://jira.blazegraph.com/browse/BLZG-1697. So this can be closed as a duplicate. If I remember correctly, we didn't consider this critical some time back (and wanted to deprecate the query hint anyways).

        Show
        michaelschmidt michaelschmidt added a comment - Having looked at the query again, I believe that neither 20601 nor 20641 are actually the desired result, but the query should yield the same number of results than the other query0021* variants, namely 20681. The 20641 results delivered by the latest branch are actually closer to the truth, they contain cases where ?_var2 is not bound. This came in at some point by a fix from Alexandre (grouping also supports grouping over null & error values -> the difference actually is that the 20641 results now also contain such cases). I also traced it down to a minimal failing query: PREFIX p1: <http: //www.rdfabout.com/rdf/schema/usgovt/> PREFIX p2: <http: //www.rdfabout.com/rdf/schema/vote/> PREFIX rdf: <http: //www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http: //www.w3.org/2000/01/rdf-schema#> SELECT (COUNT(*) AS ?cnt) WHERE { ?_var10 p2:votedBy <http: //www.rdfabout.com/rdf/usgov/congress/people/C000877>. ?_var10 rdfs:label ?_var2. hint:Prior hint:hashJoin " true " . } Funny enough, searching for this problem in JIRA, this is exactly the query I came up with a while ago: https://jira.blazegraph.com/browse/BLZG-1697 . So this can be closed as a duplicate. If I remember correctly, we didn't consider this critical some time back (and wanted to deprecate the query hint anyways).

          People

          • Assignee:
            michaelschmidt michaelschmidt
            Reporter:
            michaelschmidt michaelschmidt
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: