New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HAWQ-1122. Bump GPORCA to v1.674 and GPOS to v1.145 #978
Conversation
Any GPDB exception happens in while ORCA generating plan will abort query. This is cherry-picked from greenplum-db/gpdb@045d437 Signed-off-by: Foyzur Rahman <frahman@gmail.com>
…on.(apache#920) This is cherry-picked from greenplum-db/gpdb@36b504e
…ner for insert query This is cherry-picked from greenplum-db/gpdb@1ee7d3d
…el append (apache#977) This GUC is disabled by default. Currently, when users run an `UNION ALL` query, such as ```sql SELECT a FROM foo UNION ALL SELECT b FROM bar ```, GPDB will parallelize the execution across all the segments, but the table scans on `foo` and `bar` are not executed parallel. With this GUC enabled, we add redistribution motion node under APPEND(UNION) operator, which makes all the children of APPEND(UNION) operator execute in parallel in every segment. This is cherry-picked from greenplum-db/gpdb@86e49e5
A new feature of ORCA is to more efficiently handle array constraints. It includes a new preprocessing stage, and a new way of internally representing array constraints. This feature can be enabled by use of this GUC. This is cherry-picked from greenplum-db/gpdb@c85f858
…larArrayOpExpr [#126158185] Orca couldn't pickup plan that uses index scan for the following cases: select * from btree_tbl where a in (1,2); --> Orca generated table scan instead of index scan select * from bitmap_tbl where a in (1,2); --> Orca generated table scan instead of bitmap scan Orca failed to consider the case that uses ArrayComp when trying to pick up index. The issue has been fixed in this patch. Closes apache#993 This is cherry-picked from greenplum-db/gpdb@cfafef0
This fixes the naming in c85f858ec725ec14a6e7870749f3a03fb2597310 A new feature of ORCA is to more efficiently handle array constraints. It includes a new preprocessing stage, and a new way of internally representing array constraints. This feature can be enabled by use of this GUC. This is cherry-picked from greenplum-db/gpdb@8ba520b
…8092771] Also updated gp_optimizer expected output and ignore line number difference for functions.c This is cherry-picked from greenplum-db/gpdb@684b429
This is cherry-picked from greenplum-db/gpdb@7f10e30
…ow exception to stop execution This is cherry-picked from greenplum-db/gpdb@3868612
This is cherry-picked from greenplum-db/gpdb@29a2bed
Through the file content we know it uses personal absolute path, which can't be used by others. DisableXform/EnableXform are already built-in functions if GPDB is built with Orca. So we can safely delete this file. This is cherry-picked from greenplum-db/gpdb@1033c53
…hildren [#121181555] This is cherry-picked from greenplum-db/gpdb@30a9ed3
Signed-off-by: Omer Arap <oarap@pivotal.io>
TestExternalTable.TestExternalTableAll is expected to fail. You could check installcheck-good log, typically at least there is a file regression.diffs, but I suspect the failure is due to env setup since hcatalog_lookup seems to need a pxf service to access Hive data. |
@paul-guo- @liming01 @huor can you take it from here and merge it into the repository? Thanks. |
Moving to another PR with fixes for test cases: Please close this one. |
After the porting, HAWQ can build with
GPORCA v1.674
. However, there are few failures spotted:make installcheck-good:
src/test/feature/feature-test:
This is go beyond context of GPORCA, and we need HAWQ team to step-in, and help fixing the failed tests. @paul-guo-
https://issues.apache.org/jira/browse/HAWQ-1122