1. 29 9月, 2017 5 次提交
  2. 28 9月, 2017 13 次提交
  3. 27 9月, 2017 22 次提交
    • T
      Refers gpdb readme to orca readme for installation · d9f79353
      Todd Sedano 提交于
      - instead of trying to keep GPDB readme in sync with GPORCA readme, just refer to it
      d9f79353
    • T
      Updates conan readme for orca · 99b83339
      Todd Sedano 提交于
      - fixes cd path
      - removes macOS warning that is not currently an issue
      - treats comment like other readme comments
      99b83339
    • A
      Fix warnings for make_motion_gather_to_*(). · 8425f908
      Ashwin Agrawal 提交于
      After 7e268107 started seeing warnings like
      ------------------
      cdbgroup.c:1478:68: warning: expression which evaluates to zero treated as a null pointer constant of type 'List *' (aka 'struct List *') [-Wnon-literal-null-conversion]
                      result_plan = (Plan*)make_motion_gather_to_QE(root, result_plan, false);
                                                                                       ^~~~~
      ------------------
      8425f908
    • A
      Fix compiler warnings for ext_alloc.c. · f7748ed5
      Ashwin Agrawal 提交于
      After commit 1822c826 started seeing bunch of
      warnings like
      -------------------------------------------
      memaccounting.c:247:1: warning: no previous prototype for function 'MemoryAccounting_DeclareDone' [-Wmissing-prototypes]
      MemoryAccounting_DeclareDone()
      ^
      ../../../../src/include/utils/memaccounting.h:238:1: note: this declaration is not a prototype; add 'void' to make it a prototype for a zero-parameter function
      MemoryAccounting_DeclareDone();
      ^
                                   void
      memaccounting.c:263:1: warning: no previous prototype for function 'MemoryAccounting_RequestQuotaIncrease' [-Wmissing-prototypes]
      MemoryAccounting_RequestQuotaIncrease()
      ^
      ../../../../src/include/utils/memaccounting.h:241:1: note: this declaration is not a prototype; add 'void' to make it a prototype for a zero-parameter function
      MemoryAccounting_RequestQuotaIncrease();
      ^
                                            void
      2 warnings generated.
      ext_alloc.c:35:1: warning: no previous prototype for function 'Ext_OptimizerAlloc' [-Wmissing-prototypes]
      Ext_OptimizerAlloc(size_t size)
      ^
      ext_alloc.c:50:17: warning: unused variable 'account' [-Wunused-variable]
              MemoryAccount *account = MemoryAccounting_ConvertIdToAccount(ActiveMemoryAccountId);
                             ^
      ext_alloc.c:48:1: warning: no previous prototype for function 'Ext_OptimizerFree' [-Wmissing-prototypes]
      Ext_OptimizerFree(void *ptr)
      ^
      ext_alloc.c:59:1: warning: no previous prototype for function 'GetOptimizerOutstandingMemoryBalance' [-Wmissing-prototypes]
      GetOptimizerOutstandingMemoryBalance()
      ^
      -------------------------------------------
      f7748ed5
    • A
      Fix gp_pgdatabase__ function by including walrep state 'n'. · 49970964
      Ashwin Agrawal 提交于
      As part of commit efed2fcc new walrep state was
      added 'n' (not-in-sync). The toolkit function gp_pgdatabase__() needs to be
      modified as well to check for that state.
      
      Original code not using #defines but direct characters like 's', 'c' makes it
      very tricky find stuff in code. Hopefully, future chnages would be easy to spot
      and make.
      49970964
    • X
      Detach resource group slot on segment · 6f940543
      xiong-gang 提交于
      QE detach resource group slot at the end of transaction, the
      last QE of the slot release the slot, and release the overused
      memory if resource group config has been changed.
      6f940543
    • T
      Disable flattening of IN/EXISTS sublinks inside outer joins · fb1448d0
      Tom Lane 提交于
      commit 07b9936a
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Fri Feb 27 23:30:29 2009 +0000
      
          Temporarily (I hope) disable flattening of IN/EXISTS sublinks that are within
          the ON clause of an outer join.  Doing so is semantically correct but results
          in de-optimizing queries that were structured to take advantage of the sublink
          style of execution, as seen in recent complaint from Kevin Grittner.  Since
          the user can get the other behavior by reorganizing his query, having the
          flattening happen automatically is just a convenience, and that doesn't
          justify breaking existing applications.  Eventually it would be nice to
          re-enable this, but that seems to require a significantly different approach
          to outer joins in the executor.
      
      Added relevant test case.
      Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>
      fb1448d0
    • E
      Don't assume a subquery's output is unique if there's a SRF in its tlist · e7ff3ef1
      Ekta Khanna and Jemish Patel 提交于
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Tue Jul 8 14:03:32 2014 -0400
      
          While the x output of "select x from t group by x" can be presumed unique,
          this does not hold for "select x, generate_series(1,10) from t group by x",
          because we may expand the set-returning function after the grouping step.
          (Perhaps that should be re-thought; but considering all the other oddities
          involved with SRFs in targetlists, it seems unlikely we'll change it.)
          Put a check in query_is_distinct_for() so it's not fooled by such cases.
      
          Back-patch to all supported branches.
      
          David Rowley
      
      (cherry picked from commit 2e7469dc8b3bac4fe0f9bd042aaf802132efde85)
      e7ff3ef1
    • E
      Misc test answer file changes · 8bd49b1b
      Ekta Khanna 提交于
      Signed-off-by: NJemish Patel <jpatel@pivotal.io>
      8bd49b1b
    • E
      Fix possible crash with nested SubLinks. · cb7e418d
      Ekta Khanna 提交于
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Tue Dec 10 16:10:36 2013 -0500
      
      An expression such as WHERE (... x IN (SELECT ...) ...) IN (SELECT ...)
      could produce an invalid plan that results in a crash at execution time,
      if the planner attempts to flatten the outer IN into a semi-join.
      This happens because convert_testexpr() was not expecting any nested
      SubLinks and would wrongly replace any PARAM_SUBLINK Params belonging
      to the inner SubLink.  (I think the comment denying that this case could
      happen was wrong when written; it's certainly been wrong for quite a long
      time, since very early versions of the semijoin flattening logic.)
      
      Per report from Teodor Sigaev.  Back-patch to all supported branches.
      
      (cherry picked from commit 884c6384a2db34f6a65573e6bfd4b71dfba0de90)
      cb7e418d
    • E
      Fix planner's handling of outer PlaceHolderVars within subqueries. · 45cbf64a
      Ekta Khanna 提交于
      commit 0a0ca1cb18a34e92ab549df171e174dcce7bf7a3
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Sat Mar 24 16:22:00 2012 -0400
      
          Fix planner's handling of outer PlaceHolderVars within subqueries.
      
          For some reason, in the original coding of the PlaceHolderVar mechanism
          I had supposed that PlaceHolderVars couldn't propagate into subqueries.
          That is of course entirely possible.  When it happens, we need to treat
          an outer-level PlaceHolderVar much like an outer Var or Aggref, that is
          SS_replace_correlation_vars() needs to replace the PlaceHolderVar with
          a Param, and then when building the finished SubPlan we have to provide
          the PlaceHolderVar expression as an actual parameter for the SubPlan.
          The handling of the contained expression is a bit delicate but it can be
          treated exactly like an Aggref's expression.
      
          In addition to the missing logic in subselect.c, prepjointree.c was failing
          to search subqueries for PlaceHolderVars that need their relids adjusted
          during subquery pullup.  It looks like everyplace else that touches
          PlaceHolderVars got it right, though.
      
          Per report from Mark Murawski.  In 9.1 and HEAD, queries affected by this
          oversight would fail with "ERROR: Upper-level PlaceHolderVar found where
          not expected".  But in 9.0 and 8.4, you'd silently get possibly-wrong
          answers, since the value transmitted into the subquery wouldn't go to null
          when it should.
      45cbf64a
    • S
      Remove is_simple_subquery() check in simplify_EXISTS_query() · 77f804f5
      Shreedhar Hardikar 提交于
      GPDB handles a lot of the cases that are restricted by
      is_simple_subquery; and the restrictions not handled, are checked for
      separately in convert_EXISTS_sublink_to_join().
      
      Resulting from cascading ICG failures, we also fixed the following:
      
      - initialize all the members of IncrementVarSublevelsUp_context
        properly.
      - remove incorrect assertions brought in from upstream. In GPDB, these
        cases are handled.
      - improve plans for NOT EXISTS sub-queries containing an aggregation
        without limits by creating a "false" one-time filter.
      Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>
      77f804f5
    • S
      Remove dead code around JoinExpr::subqfromlist. · f16deabd
      Shreedhar Hardikar 提交于
      This was used to keep information about the subquery join tree for
      pulled-up sublinks for use later in deconstruct_recurse().  With the
      upstream subselect merge, a JoinExpr constructed at the pull-up time
      itself, so this is no longer needed since the subquery join tree
      information is available in the constructed JoinExpr.
      
      Also with the merge, deconstruct_recurse() handles JOIN_SEMI JoinExprs.
      However, since GPDB differs from upstream by treating SEMI joins as
      INNER join for internal join planning, this commit also updates
      inner_join_rels correctly for SEMI joins (see regression test).
      
      Also remove unused function declaration for not_null_inner_vars().
      Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>
      f16deabd
    • S
      Do not commute inner/outer rels of JOIN_ANTI and JOIN_LASJ_NOTIN · 70be2285
      Shreedhar Hardikar 提交于
      This issue was discovered during the subselect merge. wherin planner
      incorrectly commutes anti joins.
      `cdb_add_subquery_join_paths()` creates join paths for (rel1, rel2) and
      (rel2, rel1) for all join types including JOIN_ANTI and JOIN_LASJ_NOTIN.
      This produces wrong results since these joins are order-sensitive w.r.t
      inner and outer relations (see new regression tests). So, do not add
      (rel2, rel1) for JOIN_ANTI and JOIN_LASJ_NOTIN.
      
      This commit also refactors cdb_add_subquery_join_paths() and
      make_join_rel() to make it easier to control the commuting.
      Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>
      70be2285
    • S
      Handle pending merge FIXMEs from merging e549722a · cc208986
      Shreedhar Hardikar 提交于
      1. convert_IN_to_antijoin() should fail pull-up when left relids are not
         a subset of available_rels, otherwise we get wrong results. See
         regression tests in qp_correlated_query.sql.
      2. convert_EXPR_to_join() is a GPDB-only function that already handles
         this case via ProcessSubqueryToJoin().
      Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>
      cc208986
    • S
      Partial cherry-pick up of upstream commit 0dec322. · cdfc5616
      Shreedhar Hardikar 提交于
      commit 0dec3226ee905f94d0b9d6e2f274e13bbcaf5370
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Mon Jun 20 14:33:20 2011 -0400
      
          Fix thinko in previous patch for optimizing EXISTS-within-EXISTS.
      
          When recursing after an optimization in pull_up_sublinks_qual_recurse, the
          available_rels value passed down must include only the relations that are
          in the righthand side of the new SEMI or ANTI join; it's incorrect to pull
          up a sub-select that refers to other relations, as seen in the added test
          case.  Per report from BangarRaju Vadapalli.
      
      NOTE: The second part of the upstream commit is not pulled in because that
      produces inferior plans in GPDB by not pulling nested sublinks below NOT
      EXISTS. That part is reverted later upstream in 9.2 anyway.
      
      Also update regression tests.
      Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>
      cdfc5616
    • T
      Fix pull_up_sublinks' failure to handle nested pull-up opportunities · 40082bd2
      Tom Lane 提交于
      commit f3f0f37068e06d01e88abbf3ed596664b139f7e2
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Mon May 2 15:56:47 2011 -0400
      
          Fix pull_up_sublinks' failure to handle nested pull-up opportunities.
      
          After finding an EXISTS or ANY sub-select that can be converted to a
          semi-join or anti-join, we should recurse into the body of the sub-select.
          This allows cases such as EXISTS-within-EXISTS to be optimized properly.
          The original coding would leave the lower sub-select as a SubLink, which
          is no better and often worse than what we can do with a join.  Per example
          from Wayne Conrad.
      
          Back-patch to 8.4.  There is a related issue in older versions' handling
          of pull_up_IN_clauses, but they're lame enough anyway about the whole area
          that it seems not worth the extra work to try to fix.
      Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>
      40082bd2
    • T
      Fix mishandling of whole-row Vars referencing a view or sub-select · 385bb3cb
      Tom Lane 提交于
      commit c4ac2ff765d9b68a3ff2a3461804489721770d06
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Mon Jun 21 00:14:54 2010 +0000
      
          Fix mishandling of whole-row Vars referencing a view or sub-select.
          If such a Var appeared within a nested sub-select, we failed to translate it
          correctly during pullup of the view, because the recursive call to
          replace_rte_variables_mutator was looking for the wrong sublevels_up value.
          Bug was introduced during the addition of the PlaceHolderVar mechanism.
          Per bug #5514 from Marcos Castedo.
      385bb3cb
    • D
      Fix an oversight in convert_EXISTS_sublink_to_join · d3ff95a1
      Dhanashree Kashid 提交于
      commit dcd647d7cf98e3393f919135f6e113e896781f60
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Mon Jan 18 18:17:52 2010 +0000
      
          Fix an oversight in convert_EXISTS_sublink_to_join: we can't convert an
          EXISTS that contains a WITH clause.  This would usually lead to a
          "could not find CTE" error later in planning, because the WITH wouldn't
          get processed at all.  Noted while playing with an example from Ken Marshall.
      d3ff95a1
    • T
      Move exprType,exprTypmod,expression_tree_walker and related routines · e65f963b
      Tom Lane 提交于
        commit e5536e77
        Author: Tom Lane <tgl@sss.pgh.pa.us>
        Date:   Mon Aug 25 22:42:34 2008 +0000
      
            Move exprType(), exprTypmod(), expression_tree_walker(), and related routines
            into nodes/nodeFuncs, so as to reduce wanton cross-subsystem #includes inside
            the backend.  There's probably more that should be done along this line,
            but this is a start anyway
      Signed-off-by: NShreedhar Hardikar <shardikar@pivotal.io>
      e65f963b
    • T
      Change EXPLAIN output so that subplans and initplans · acfd5f4d
      Tom Lane 提交于
      commit fbcce080
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Sun Apr 5 19:59:40 2009 +0000
      
          Change EXPLAIN output so that subplans and initplans (particularly CTEs)
          are individually labeled, rather than just grouped under an "InitPlan"
          or "SubPlan" heading.  This in turn makes it possible for decompilation of
          a subplan reference to usefully identify which subplan it's referencing.
          I also made InitPlans identify which parameter symbol(s) they compute,
          so that references to those parameters elsewhere in the plan tree can
          be connected to the initplan that will be executed.  Per a gripe from
          Robert Haas about EXPLAIN output of a WITH query being inadequate,
          plus some longstanding pet peeves of my own.
      acfd5f4d
    • T
      Don't try to optimize EXISTS subqueries with empty FROM-lists · 16d21117
      Tom Lane 提交于
      commit 173a6760
      Author: Tom Lane <tgl@sss.pgh.pa.us>
      Date:   Mon Dec 8 00:16:09 2008 +0000
      
          Don't try to optimize EXISTS subqueries with empty FROM-lists: we need to
          form a join and that case doesn't have anything to join to.  (We could
          probably make it work if we didn't pull up the subquery, but it seems to
          me that the case isn't worth extra code.)  Per report from Greg Stark.
      16d21117