- 29 9月, 2020 1 次提交
-
-
由 Jesse Zhang 提交于
The canonical config file is in src/backend/gpopt/.clang-format (instead of under the non-existent src/backend/gporca), I've created one (instead of two) symlink, for GPOPT headers. Care has been taken to repoint the symlink to the canonical config under gpopt, instead of gpopt as it is under HEAD. This is spiritually a cherry-pick of commit 2f7dd76c. (cherry picked from commit 2f7dd76c)
-
- 01 6月, 2019 1 次提交
-
-
由 Chris Hajas 提交于
The IMemoryPool interface was removed in ORCA to remove an unnecessary abstraction layer and avoid costly casting. Corresponding ORCA commit: e64a2b42 Bumps ORCA version to 3.46.0 Authored-by: NChris Hajas <chajas@pivotal.io>
-
- 01 3月, 2019 1 次提交
-
-
由 Abhijit Subramanya 提交于
Prior to this patch, the MCVs for text columns was not being passed to ORCA. Hence the cardinality estimation for predicates involving text was inaccurate and led to sub optimal plans being picked. This patch allows the MCVs to be passed in to ORCA so that it can now estimate the cardinality using MCVs equal and not equal operators for text columns. Co-authored-by: NAbhijit Subramanya <asubramanya@pivotal.io> Co-authored-by: NBhuvnesh Chaudhary <bchaudhary@pivotal.io>
-
- 24 8月, 2018 1 次提交
-
-
由 Heikki Linnakangas 提交于
I was getting a compiler warning from it: CTranslatorUtils.cpp: In static member function ‘static gpos::BOOL gpdxl::CTranslatorUtils::IsGroupingColumn(const SortGroupClause*, List*)’: CTranslatorUtils.cpp:2079:42: warning: self-comparison always evaluates to true [-Wtautological-compare] if (sort_group_clause->tleSortGroupRef == sort_group_clause->tleSortGroupRef) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ But since the function doesn't seem to be used anywhere, let's just remove it, instead of trying to fix it.
-
- 16 8月, 2018 1 次提交
-
-
由 Bhuvnesh Chaudhary 提交于
As part of moving away from Hungarian notation in the GPORCA codebase, the integration points between GPORCA and GPDB in the translator have been renamed to the new convention used in GPORCA. The libraries currently updated to the new notation in GPORCA are Naucrates and GPOS. The new naming convention is a custom version of common C++ naming conventions. The style guide for this convention can be found in the GPORCA repository. Also bump ORCA version to 2.69.0 Co-authored-by: NShreedhar Hardikar <shardikar@pivotal.io> Co-authored-by: NMelanie Plageman <mplageman@pivotal.io> Co-authored-by: NEkta Khanna <ekhanna@pivotal.io> Co-authored-by: NAbhijit Subramanya <asubramanya@pivotal.io> Co-authored-by: NSambitesh Dash <sdash@pivotal.io><Paste> Co-authored-by: NDhanashree Kashid <dkashid@pivotal.io> Co-authored-by: NOmer Arap <oarap@pivotal.io>
-
- 15 2月, 2018 1 次提交
-
-
由 Jesse Zhang 提交于
ORCA has historically ignored type modifiers from databases that support them, noticeably Postgres and Greenplum. This has led to surprises in a few cases: 1. The output description over the wire (for Postgres protocol) will lose the type modifier information, which often meant length. This surprises code that expects a non-default type modifier, e.g. a JDBC driver. 2. The executor in some cases -- notably DML -- expects a precise type modifier. Because ORCA always erases the type modifiers and presents a default, the executor is forced to find that information elsewhere. After this commit, ORCA will be aware of type modifiers in table columns, scalar identifiers, constants, and length-coercion casts. Signed-off-by: NShreedhar Hardikar <shardikar@pivotal.io> (cherry picked from commit 2d907526)
-
- 15 9月, 2017 1 次提交
-
-
由 Omer Arap 提交于
GPORCA should not spend time extracting column statistics that are not needed for cardinality estimation. This commit eliminates this overhead of requesting and generating the statistics for columns that are not used in cardinality estimation unnecessarily. E.g: `CREATE TABLE foo (a int, b int, c int);` For table foo, the query below only needs for stats for column `a` which is the distribution column and column `c` which is the column used in where clause. `select * from foo where c=2;` However, prior to that commit, the column statistics for column `b` is also calculated and passed for the cardinality estimation. The only information needed by the optimizer is the `width` of column `b`. For this tiny information, we transfer every stats information for that column. This commit and its counterpart commit in GPORCA ensures that the column width information is passed and extracted in the `dxl:Relation` metadata information. Preliminary results for short running queries provides up to 65x performance improvement. Signed-off-by: NJemish Patel <jpatel@pivotal.io>
-
- 22 8月, 2017 1 次提交
-
-
由 Heikki Linnakangas 提交于
This is potentially a tiny bit faster, if the coercion can be performed just once at parse/plan time, rather than on every row. This fixes some of the bogus error checks and inconsistencies in handling the ROWS expressions. For example, before, if you passed a string constant as the ROWS expression, you got an error, but if you passed a more complicated expression, that returned a string, the string was cast to an integer at runtime. And those casts evaded the plan-time checks for negative values. Also, move the checks for negative ROWS/RANGE value from the parser to the beginning of execution, even in the cases where the value is a constant, or a stable expression that only needs to be executed once. We were missing the checks in ORCA, so this fixes the behavior with ORCA for such queries.
-
- 22 6月, 2017 1 次提交
-
-
Instead we should maintain NDVRemain and NullFreq to do Cardinality Estimation. Adding function to check if we need to create stats bucket in DXL Function `FCreateStatsBucket` returns true if column data type is not a text/varchar/char/bpchar type. Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>
-
- 24 1月, 2017 1 次提交
-
-
由 Dhanashree Kashid 提交于
After 8.3 merge, gpdb has new polymorphic types, ANYENUM and ANYNONARRAY. This fix adds support for ANYENUM and ANYNONARRAY in Translator. As per postgreSQL, when a function has polymorphic arguments and results; in the function call they must have the same actual type. For example, a function declared as `f(ANYARRAY) returns ANYENUM` will only accept arrays of enum types. We already have this resolution logic implemented in `resolve_polymorphic_argtypes()`. Refactor the code in `PdrgpmdidResolvePolymorphicTypes()` to use `resolve_polymorphic_argtypes()` to deduce the correct data type for function argument and return type, based on function call. Signed-off-by: NBhuvnesh Chaudhary <bchaudhary@pivotal.io> Signed-off-by: NOmer Arap <oarap@pivotal.io>
-
- 18 1月, 2017 1 次提交
-
-
由 Dhanashree Kashid 提交于
With PostgreSQL 8.3, there's a new concept called "operator families". An operator class is now part of an operator family, which can contain cross-datatype operators that are "compatible" with each other. ORCA doesn't know anything about that. This commit updates the Translator files to refer to OpFamily instead of 'OpClasses'. ORCA still doesn't take advantage of this, but at least we are using operator families in operator classes' stead to make indexes work. Signed-off-by: NHaisheng Yuan <hyuan@pivotal.io>
-
- 10 11月, 2016 1 次提交
-
-
由 Heikki Linnakangas 提交于
A bunch of functions and classes that are not used anywhere.
-
- 19 5月, 2016 1 次提交
-
-
- 03 2月, 2016 1 次提交
-
-
由 Venkatesh Raghavan 提交于
-
- 24 11月, 2015 1 次提交
-
-
由 Venkatesh Raghavan 提交于
-
- 28 10月, 2015 1 次提交
-
-