Uploaded image for project: 'Ignite'
  1. Ignite
  2. IGNITE-16315

Calcite engine. Query start request contains a lot of data

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • None
    • None

    Description

      For simple queries SQL engine most of the time spend in writing/reading query start requests, which contains a lot of data. Nested instances of ColocationGroup class contain assignments for each partition (List<List<UUID>>). Transferred size can be reduced if we compact assignments somehow. The target colocation group from fragment description contains redundant synthetic partitions, this also can be optimized.

      Messages workflow is not optimal too. First, we send QueryStartRequest to the remote nodes, remotes reply with the QueryStartResponse messages. After that remotes send batches with data to the target nodes and receive acks for each batch (acks required to limit inbox workload). When query execution is finished, the node initiator sends QueryCloseMessage to the remote nodes, remotes close queries, and sends back ErrorMessage to the initiator with the ExecutionCancelledException error (which is ignored on the initiator node).  

      Also, some other optimizations are possible. Proposed changes:

      • Implement compaction of assignments of ColocationGroup
      • Reduce target colocation group partitions count
      • Fix caching of query plans (store original SQL as key, not parsed SQL, to avoid redundant parsing)
      • Change messages workflow (don't send ack messages for the last batch since it is redundant, self-close remote queries, and don't send close query messages to remote nodes, if we know for sure that it's already self-closed, don't send query start response if we already have sent batch for the same fragment before)
      • Reduce count of RexBuilder creation on the execution phase (RexBuilder is stateless and can be used one static instance)
      • Reduce count of Calcite types creation on the execution phase

      Attachments

        Issue Links

          Activity

            People

              alex_pl Aleksey Plekhanov
              alex_pl Aleksey Plekhanov
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 5h 50m
                  5h 50m