- 10 10月, 2017 7 次提交
-
-
由 Ashwin Agrawal 提交于
-
由 Ashwin Agrawal 提交于
-
由 Ashwin Agrawal 提交于
-
由 Ashwin Agrawal 提交于
-
由 Ashwin Agrawal 提交于
-
由 Ashwin Agrawal 提交于
-
由 Bhuvnesh Chaudhary 提交于
If a target list entry is found under a relabelnode, the newly created var node should be nested inside the relabelnode if the vartype of the var node is different than the resulttype of the relablenode. Otherwise, the cast information is lost and executor will complain type mismatch ```sql CREATE TABLE t1 (a varchar, b character varying) DISTRIBUTED RANDOMLY; SELECT array_agg(f) FROM (SELECT b::text as f FROM t1 GROUP BY b) q; ERROR: attribute 1 has wrong type (execQual.c:763) (seg0 slice2 127.0.0.1:25432 pid=7064) DETAIL: Table has type character varying, but query expects text. ```
-
- 09 10月, 2017 1 次提交
-
-
由 Richard Guo 提交于
Previously there is a restriction on GUC 'max_resource_groups' that it cannot be larger than 'max_connections'. This restriction may cause gpdb fail to start if the two GUCs are not set properly. We decide to decouple these two GUCs and set a hard limit of 100 for 'max_resource_groups'.
-
- 04 10月, 2017 1 次提交
-
-
由 Heikki Linnakangas 提交于
Upstream commit 220db7cc replaced all the idiomatic DirectFunctionCalls of textin/textout, to use these new handy macros instead. Do the same for all the remaining such calls in GPDB-specific code.
-
- 30 9月, 2017 3 次提交
-
-
由 Ning Yu 提交于
A slot maybe reused on QE while its still using by another QE which might causes runtime error. This issue exists for a long time in theory, but the fail rate is enlarged with a current commit 8005f559. To workaround the issue we change the free slot pool from a stack into a queue, slots are allocated from the head and freed to the tail, so a slot will not be reused immediately after being freed. In worst case all the in-use slots are not freed in time on QEs, so we also doubled the slot pool size to have enough free slots for new queries even in such a worst case. In any sense this is not a fix, just a quick workaround, we will keep working on this race condition issue. Once a root fix is ready this workaround will be replaced.
-
由 Haisheng Yuan 提交于
Don't transform large array Const into ArrayExpr for Orca (#3406) If the number of elements in the array Const is greater than optimizer_array_expansion_threshold, returns the original Const unmodified. Otherwise, it will cause severe performance issue for Orca optimizer for array with very large number of elements, e.g. 50K. Fixes issue #3355 [#151340976]
-
由 Kavinder Dhaliwal 提交于
Explain analyze with explain_memory_verbosity set to 'detail' or 'summary' will show total memory used accross slices We will be adding an extra line detailing total memory used across slices to explain analyze. This will help us in profiling memory usage from TPC-DS benchmark. ``` (slice0) Executor memory: 322K bytes. Peak memory: 11783K bytes. Vmem reserved: 12288K bytes. (slice1) Executor memory: 8375K bytes avg x 3 workers, 8375K bytes max (seg0). Peak memory: 9488K bytes avg x 3 workers, 9488K bytes max (seg0). Vmem reserved: 9216K bytes avg x 3 workers, 9216K bytes max (seg0). Total memory used across slices: 40247K bytes Statement statistics: Memory used: 128000K bytes ``` Signed-off-by: NSambitesh Dash <sdash@pivotal.io>
-
- 29 9月, 2017 3 次提交
-
-
由 Ning Yu 提交于
* resgroup: provide helper function to wakeup a proc. * resgroup: provide helper function to check resWaiting. * resgroup: refine the logic in ResGroupWaitCancel(). * resgroup: error out in ResGroupHashFind() directly. * resgroup: error out in ResGroupHashRemove() directly. * resgroup: add an arg `grant` in wakeupSlots(). * resgroup: move resWaiting updates into WaitQueue helper funcs. * resgroup: cleanup the duplicate wakeup logic in ResGroupSlotRelease(). * resgroup: fix typo in function name groupAssignChunks(). * resgroup: rename groupAssignChunks() to groupRebalanceQuota(). * resgroup: polish comments for groupApplyMemCaps(). * resgroup: add comments for ResGroup{Caps,Opts}. * resgroup: cleanup obsolete declarations in resgroup.h * resgroup: use int32 instead of uint32 for self->memUsage. * resgroup: correct the slot cleanup in ResGroupWaitCancel(). * resgroup: do not error out in transaction callbacks.
-
由 Ashwin Agrawal 提交于
-
由 Ashwin Agrawal 提交于
These tables seem dead and were only used before 4.0 era, hence removing them now from catalog.
-
- 28 9月, 2017 3 次提交
-
-
由 Richard Guo 提交于
Previously every resource group has its own slot pool, each with size of 'MaxConnection'. In order to reduce memory usage, implement a slot pool shared by all resource groups. In addition, free slots in the slot pool are organized as a free list to optimize alloc/free operations.
-
由 Ekta Khanna 提交于
In copyFuncs(), the fallthrough for SpecialJoinInfo was unintentionally done as a part of subselect merge. This commit fixes that along with adding support for new fields in copyFuncs(), outFunc() and equalFunc() [Ref #151491231] Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>
-
由 Ashwin Agrawal 提交于
-
- 27 9月, 2017 22 次提交
-
-
由 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); ^~~~~ ------------------
-
由 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() ^ -------------------------------------------
-
由 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.
-
由 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.
-
由 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>
-
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)
-
由 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)
-
由 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.
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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.
-
由 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.
-
由 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>
-
由 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.
-
由 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.
-
We had a bunch of fixmes that we added as part of the subselect merge; All of the fixmes are now marked as `GPDB_84_MERGE_FIXME` so that they can be grepped easily.
-
由 Dhanashree Kashid 提交于
commit dc9cc887b74bfa0d40829c4df66dead509fdd8f6 Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Tue Sep 28 14:15:42 2010 -0400 The point of a PlaceHolderVar is to allow a non-strict expression to be evaluated below an outer join, after which its value bubbles up like a Var and can be forced to NULL when the outer join's semantics require that. However, there was a serious design oversight in that, namely that we didn't ensure that there was actually a correct place in the plan tree to evaluate the placeholder :-(. It may be necessary to delay evaluation of an outer join to ensure that a placeholder that should be evaluated below the join can be evaluated there. Per recent bug report from Kirill Simonov. Back-patch to 8.4 where the PlaceHolderVar mechanism was introduced. Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>
-
由 Dhanashree Kashid 提交于
commit 2bdd765f79df947b46a8b5a22e3b993b58cd6d32 Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Wed Sep 2 17:52:33 2009 +0000 Fix subquery pullup to wrap a PlaceHolderVar around the entire RowExpr that's generated for a whole-row Var referencing the subquery, when the subquery is in the nullable side of an outer join. The previous coding instead put PlaceHolderVars around the elements of the RowExpr. The effect was that when the outer join made the subquery outputs go to null, the whole-row Var produced ROW(NULL,NULL,...) rather than just NULL. There are arguments afoot about whether those things ought to be semantically indistinguishable, but for the moment they are not entirely so, and the planner needs to take care that its machinations preserve the difference. Per bug #5025. Making this feasible required refactoring ResolveNew() to allow more caller control over what is substituted for a Var. I chose to make ResolveNew() a wrapper around a new general-purpose function replace_rte_variables(). I also fixed the ancient bogosity that ResolveNew might fail to set a query's hasSubLinks field after inserting a SubLink in it. Although all current callers make sure that happens anyway, we've had bugs of that sort before, and it seemed like a good time to install a proper solution. Back-patch to 8.4. The problem can be demonstrated clear back to 8.0, but the fix would be too invasive in earlier branches; not to mention that people may be depending on the subtly-incorrect behavior. The 8.4 series is new enough that fixing this probably won't cause complaints, but it might in older branches. Also, 8.4 shows the incorrect behavior in more cases than older branches do, because it is able to flatten subqueries in more cases. Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>
-