-
Notifications
You must be signed in to change notification settings - Fork 100
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
Cherry-pick gporca commits to fix Bug 669 #708
base: main
Are you sure you want to change the base?
Conversation
- Fix off-by-one error in 71dd8b0239 - Add optimizer_trace_fallback to catch issue in non-assert build
Tests still failed - patch did not help The good news it's stable reproduced in my dev env, script for it -
|
Issue is that if a predicate with a set-returning function is pushed down then it can lead to bad execution because there exist cases where the below context cannot accept a set. Logic already existed to prevent such a case, but it wasn't sufficient. Following example demonstrates such a case: ```sql CREATE TABLE t(a int[]) ; INSERT INTO t VALUES (ARRAY[1, 2]); SELECT * FROM (SELECT unnest(t1.a) a_unnest FROM t t1, t t2) s WHERE a_unnest IS NOT NULL; ``` Also similarly, do not push down a filter through a projected column containing a subquery.
Commit Oct 4, 2022 "[ORCA] Avoid pushdown of predicate with set-returning function (#14201)" fixed the issue Tests in my dev env:
PR could be reviewed now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, let us waiting the CI re-enable.
Here I chery-picked
Jul 30, 2022 Fix qp_with_clause testcase without asserts (#13878)
Oct 4, 2022 [ORCA] Avoid pushdown of predicate with set-returning function (#14201)
fix #669
Change logs
Describe your change clearly, including what problem is being solved or what feature is being added.
If it has some breaking backward or forward compatibility, please clary.
Why are the changes needed?
Describe why the changes are necessary.
Does this PR introduce any user-facing change?
If yes, please clarify the previous behavior and the change this PR proposes.
How was this patch tested?
Please detail how the changes were tested, including manual tests and any relevant unit or integration tests.
Contributor's Checklist
Here are some reminders and checklists before/when submitting your pull request, please check them:
make installcheck
make -C src/test installcheck-cbdb-parallel
cloudberrydb/dev
team for review and approval when your PR is ready🥳