Details

    • Type: Bug
    • Status: Closed - Won't Fix
    • Resolution: Duplicate
    • Affects Version/s: BIGDATA_RELEASE_1_2_0
    • Fix Version/s: None
    • Component/s: Query Engine
    • Labels:
      None

      Description

      The issue is the following pattern where we have multiple OPTIONAL blocks nested within another OPTIONAL:

      OPTIONAL {
      OPTIONAL{
      }
      OPTIONAL {
      }
      }

      During execution, this pattern seems to result in heavy memory consumption along with blocking buffer warning messages. Changing the pattern to the following improves the situation significantly:

      OPTIONAL {
      OPTIONAL{
      {
      }
      UNION
      {
      }
      }
      }

      If the old query consumed 300Mb and took many seconds to execute, the new one causes not more than 25Mb of heap and returns in a milliseconds.

      On the other hand, having multiple OPTIONALs, but not more than one OPTIONAL at each level seems to have no such negative impact. So question: is this pattern known to cause issues, and something we should document to avoid in general?

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        This is a duplicate for [1].

        [1] https://sourceforge.net/apps/trac/bigdata/ticket/668 (JoinGroup optimizations).

        Show
        bryanthompson bryanthompson added a comment - This is a duplicate for [1] . [1] https://sourceforge.net/apps/trac/bigdata/ticket/668 (JoinGroup optimizations).

          People

          • Assignee:
            mikepersonick mikepersonick
            Reporter:
            mikepersonick mikepersonick
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: