- 08 9月, 2017 18 次提交
-
-
由 Daniel Gustafsson 提交于
Use the available macro for detecting FTP protocol and use pstrdup instead of palloc+strncpy. Also fix a spacing issue with an ereport call.
-
由 Daniel Gustafsson 提交于
-
由 Heikki Linnakangas 提交于
Mostly, move the responsibilities of the check_call() function to the callers, transformAggregateCall() and transformWindowFuncCall(). This fixes one long-standing, albeit harmless, bug. Previously, you got an "Unexpected internal error", if you tried to use a window function in the WHERE clause of a DELETE statement, instead of a user-friendly syntax error. Add a test case for that. Move a few similar tests from 'olap_window_seq' to 'qp_olap_windowerr'. Seems like a more appropriate place for them. Also, 'olap_window_seq' has an alternative expected output file for ORCA, so it's nice to keep tests that produce the same output with or without ORCA out of there. Also add a test query for creating an index on an expression containing a window function. There was a test for that already, but it was missing parens around the expression, and therefore produced an error already in the grammar.
-
由 Adam Lee 提交于
The other one is <SEG_DATA_DIR>, they should keep the same style.
-
由 Nadeem Ghani 提交于
In GpMirrorListToBuild.buildMirrors() if there are no mirrors to build, then return True, so that gprecoverseg returns a return code of 0. Signed-off-by: NShoaib Lari <slari@pivotal.io> Signed-off-by: NNadeem Ghani <nghani@pivotal.io>
-
由 Mel Kiyama 提交于
-
由 Mel Kiyama 提交于
-
由 Ashwin Agrawal 提交于
-
由 Ashwin Agrawal 提交于
Deleting unused function CreateCurlHandler and make some other functions static to avoid warnings.
-
由 Ashwin Agrawal 提交于
With commit cedd89bf "Simplify tuple serialization in Motion nodes.", the usage for this function was removed.
-
由 Ashwin Agrawal 提交于
These functions as inline functions were producing warnings, based on discussion https://groups.google.com/a/greenplum.org/d/msg/gpdb-dev/6fgKvN9QpV4/zjysjqIZAgAJ converting them to macro as upstream. Adding explicit type casting wherever needed now that DatumGetPointer() returns (char *) instead of (void *).
-
由 Ashwin Agrawal 提交于
-
由 Ashwin Agrawal 提交于
Compiling hstore was generating the warning for using deprecated function heap_formtuple(). Fixing to use the newer one heap_form_tuple().
-
由 Peter Eisentraut 提交于
This avoids a warning from clang 3.2 about an uninitialized variable 'dtype' in date_in().
-
This commit removes Query::hasModifyingCTE and ParseState::p_hasModifyingCTE because they are dead code. This change impacts reading and writing `pg_rewrite` rules, which is how views are implemented, and hence won't be backported to 5.0 or ealier. A `pg_upgrade` from 5 to 6 will still work because this change has no DDL surface.
-
由 Shoaib Lari 提交于
* whitespace reformat Signed-off-by: NShoaib Lari <slari@pivotal.io> * gprecverseg unit test: remove redundancy Signed-off-by: NShoaib Lari <slari@pivotal.io> * Fix gprecoverseg recursive behavior gprecoverseg called itself during a rebalance, through a Command object. But this command didn't signal failures through a non-zero ret-code. So the top-level gprecoverseg didn't check its stdout/stderr for error messages and didn't echo them to its own stdout, though they were being logged. This commit changes behavior so gprecoverseg make another object and invokes its run() method. Any errors are now shown to the user and logged. Signed-off-by: NMarbin Tan <mtan@pivotal.io> Signed-off-by: NNadeem Ghani <nghani@pivotal.io>
-
- 07 9月, 2017 22 次提交
-
-
由 Heikki Linnakangas 提交于
Refactor the EDGE_IS_* macros so that they take the current WindowStatePerLevel as argument, rather than a WindowFrameEdge. This will make the transition to the upstream window function implementation a bit easier, because the upstream implementation doesn't have a WindowFrameEdge struct. Encapsulate access to level_state->is_rows in a macro. This is also in preparation for the upstream implementation, which will contain that information as a flag in the frameOptions bitmask. Many functions used an 'is_lead' argument, and one used 'is_trail', to keep track whether we're dealing with the leading or trailing edge. Introduce a little enum with EDGE_TRAIL and EDGE_LEAD values, to avoid having to remember what 'true' or 'false' means in which context.
-
由 Weinan WANG 提交于
This reverts commit 118ab14f.
-
由 Heikki Linnakangas 提交于
In principle, it makes sense to determine at plan-time, whether the expression needs to be re-evaluated for every row. In practice, it seems simpler to decide that in the executor, when initializing the Window node. This allows removing a bunch of code from the planner, and from the ORCA translator, including the hack to force the expression to be delayed if it was a SubLink. The planner always set the delayed flag, unless the expression was a Const. We can easily and quickly check for that in the executor too. I'm not sure how ORCA decided whether to delay or not, but in some quick testing I cannot come up with a case where it would decide differently.
-
由 Heikki Linnakangas 提交于
The big difference is that each leaf query is now transformed in one go, like it's done in the upstream, instead of transforming the target list and FROM list first. That partial transformation was causing trouble for another refactoring that I'm working on, which ill change the way window functions are handled in parse analysis. This two-pass code is GPDB-specific, PostgreSQL uses a simpler algorithm that works bottom-up, one setop node at a time, to select the column types.
-
由 Heikki Linnakangas 提交于
It hasn't been implemented, but there is basic support in the grammar, just enough to detect the syntax and throw an error or ignore it. All the rest was dead code.
-
由 Heikki Linnakangas 提交于
The feature was removed in GPDB 5. Apparently no-one has been running these tests, because they'd fail.
-
由 Gang Xiong 提交于
comment out several tests which will fail on CCP cluster
-
由 Richard Guo 提交于
Verify the newval for GUC 'statement_mem' and 'max_resource_groups' only if they are actually being set. In the process of starting gpdb, one step is to check if all GUCs are valid with new values, but without actually setting them.
-
由 Jim Doty 提交于
-
由 Todd Sedano 提交于
-
由 Todd Sedano 提交于
This makes the linux directions look more like the macOS directions for the top level readme.
-
由 Shivram Mani 提交于
* Updated PXF notice and licensing info * Updated PXF notice and licensing info
-
由 Alexander Denissov 提交于
-
由 Dhanashree 提交于
-
Currently ORCA does not support index scan on leaf partitions. It only supports index scan if we query the root table. This commit along with the corresponding ORCA changes adds a support for using indexes when leaf partitions are queried directly. When a root table that has indexes (either homogenous/complete or heterogenous/partial) is queried; the Relcache Translator sends index information to ORCA. This enables ORCA to generate an alternative plan with Dynamic Index Scan on all partitions (in case of homogenous index) or a plan with partial scan i.e. Dynamic Table Scan on leaf partitions that don’t have indexes + Dynamic Index Scan on leaf partitions with indexes (in case of heterogeneous index). This is a two step process in Relcache Translator as described below: Step 1 - Get list of all index oids `CTranslatorRelcacheToDXL::PdrgpmdidRelIndexes()` performs this step and it only retrieves indexes on root and regular tables; for leaf partitions it bails out. Now for root, list of index oids is nothing but index oids on its leaf partitions. For instance: ``` CREATE TABLE foo ( a int, b int, c int, d int) DISTRIBUTED by (a) PARTITION BY RANGE(b) (PARTITION p1 START (1) END (10) INCLUSIVE, PARTITION p2 START (11) END (20) INCLUSIVE); CREATE INDEX complete_c on foo USING btree (c); CREATE INDEX partial_d on foo_1_prt_p2 using btree(d); ``` The index list will look like = { complete_c_1_prt_p1, partial_d } For a complete index, the index oid of the first leaf partitions is retrieved. If there are partial indexes, all the partial index oids are retrieved. Step 2 - Construct Index Metadata object `CTranslatorRelcacheToDXL::Pmdindex()` performs this step. For each index oid retrieved in Step #1 above; construct an Index Metadata object (CMDIndexGPDB) to be stored in metadata cache such that ORCA can get all the information about the index. Along with all other information about the index, `CMDIndexGPDB` also contains a flag `fPartial` which denotes if the given index is homogenous (if yes, ORCA will apply it to all partitions selected by partition selector) or heterogenous (if yes, the index will be applied to only appropriate partitions). The process is as follows: ``` Foreach oid in index oid list : Get index relation (rel) If rel is a leaf partition : Get the root rel of the leaf partition Get all the indexes on the root (this will be same list as step #1) Determine if the current index oid is homogenous or heterogenous Construct CMDIndexGPDB based appropriately (with fPartial, part constraint, defaultlevels info) Else: Construct a normal CMDIndexGPDB object. ``` Now for leaf partitions, there is no notion of homogenous or heterogenous indexes since a leaf partition is like a regular table. Hence in `Pmdindex()` we should not got for checking if index is complete or not. Additionally, If a given index is homogenous or heterogenous needs to be decided from the perspective of relation we are querying(such as root or a leaf). Hence the right place of `fPartial` flag is in the relation metadata object (CMDRelationGPDB) and not the independent Index metadata object (CMDIndexGPDB). This commit makes following changes to support index scan on leaf partitions along with partial scans : Relcache Translator: In Step1, retrieve the index information on the leaf partition and create a list of CMDIndexInfo object which contain the index oid and `fPartial` flag. Step 1 is the place where we know what relation we are querying which enable us to determine whether or not the index is homogenous from the context of the relation. The relation metadata tag will look like following after this change: Before: ``` <dxl:Indexes> <dxl:Index Mdid="0.17159874.1.0"/> <dxl:Index Mdid="0.17159920.1.0"/> </dxl:Indexes> ``` After: ``` <dxl:IndexInfoList> <dxl:IndexInfo Mdid="0.17159874.1.0" IsPartial="true"/> <dxl:IndexInfo Mdid="0.17159920.1.0" IsPartial="false"/> </dxl:IndexInfoList> ``` A new class `CMDIndexInfo` has been created in ORCA which contains index mdid and `fPartial` flag. For external tables, normal tables and leaf partitions; the `fPartial` flag will always be false. Hence at the end, relcache translator will provide list of indexes defined on leaf partitions when they are queried directly with `fPartial` being false always. And when root table is queried; the `fPartial` will be set appropriately based on the completeness of the index. ORCA will refer to Relation Metadata for fPartial information and not to the indepedent Index Metadata Object. [Ref ##120303669]
-
由 Shivram Mani 提交于
-
由 Heikki Linnakangas 提交于
* In ruleutils.c, the ereport() was broken. Use elog() instead, like in the upstream. (elog() is fine for "can't happen" kind of sanity checks) * Remove a few unused local variables. * Add a missing cast from Plan * to Node *.
-
-
由 Jesse Zhang 提交于
We will be less conservative and enable by default recursive CTE on master, while keeping recursive CTE hidden as we progress on developing the feature. This reverts the following two commits: * 280c577a "Set gp_recursive_cte_prototype GUC to true in test" * 4d5f8087 "Guard Recursive CTE behind a GUC" Signed-off-by: NHaisheng Yuan <hyuan@pivotal.io> Signed-off-by: NJesse Zhang <sbjesse@gmail.com>
-
由 Heikki Linnakangas 提交于
In a stand-alone backend ("postgres --single"), you cannot realistically expect any of the infrastructure needed for MPP processing to be present. Let's force a stand-alone backend to run in utility mode, to make sure that we don't try to dispatch queries, participate in distributed transactions, or anything like that, in a stand-alone backend. Fixes github issue #3172, which was one such case where we tried to dispatch a SET command in single-user mode, and got all confused.
-
由 Jemish Patel 提交于
Previously we were setting the value of `optimizer_join_arity_for_associativity_commutativity` to very large number and so ORCA would spend a very long time evaluating all possible n_way_join combinations to come up with the cheapest join tree to use in the plan. We are reducing this value to `7` as it does not prove to be beneficial to spend time and resources to evaluate any more than 7_way_joins in trying to find the cheapest join tree.
-
由 Kris Macoskey 提交于
The upstream repository for the resource type has been renamed. There are no changes to the functionality, just a change of name.
-