Commits on Oct 10, 2020

1. opt,sql: use paired joins for left outer spatial joins …

   The GenerateInvertedJoins rule now fires for left outer joins
   GenerateInvertedJoins in custom_funcs.go builds the two
   RelExprs and the continuation col ID. execbuilder.Builder
   makes the adjustments for outputting the continuation column
   for the inverted join (the first join in the pair). There
   are similar changes in execFactory.ConstructInvertedJoin and in
   DistSQLPlanner.createPlanForInvertedJoin.
   
   I could not figure out a simpler way that did not require
   changes in all these places since the continuation column
   is synthesized, and not part of the input or the scan of
   the right side.
   
   To prevent a sort from being interposed between the first
   and second join, there is a change to
   lookupOrIndexJoinCanProvideOrdering. This is currently
   the only known case where the optimizer can interpose
   an operation that would break the behavior of the
   continuation column. DistSQLPlanner always uses
   PhysicalPlan.AddNoGroupingStage when planning the second
   join, which ensures that the second join processors are
   on the same node as the first join processors, so there is
   no danger of breaking the one-to-one relationship needed
   between the two processors.
   
   In addition to being more efficient than the current
   transformation for left outer joins, I noticed in the
   output in inverted_join_geospatial_dist that the current
   transformation was not distributed while the paired joins
   are distributed.
   
   This PR does not include left semi and left anti joins which
   will be in later PRs.
   
   Release note (performance improvement): more efficient plan
   for execution of left outer spatial joins.

   

   sumeerbhola committed Oct 10, 2020
   Configuration menu

   • View commit details
   • Copy full SHA for 051263f
   • Browse repository at this point

   Copy the full SHA

   051263f View commit details

   Browse the repository at this point in the history