-
Notifications
You must be signed in to change notification settings - Fork 3
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
Agg pushdown v2 #2
Conversation
I see one more issue here, and that is that PG isn't rechecking quals for pushed aggregations: sgr@localhost:splitgraph> SELECT count(*) FROM es.account WHERE firstname ~~ 'Su_an%'
+-------+
| count |
|-------|
| 4 |
+-------+
SELECT 1
Time: 0.019s
sgr@localhost:splitgraph> SELECT count(*) FROM es.account WHERE firstname !~~ 'Su_an%'
+-------+
| count |
|-------|
| 1000 |
+-------+
SELECT 1
Time: 0.013s
sgr@localhost:splitgraph> select count(1) FROM es.account WHERE firstname !~~ 'Su_an%'
+-------+
| count |
|-------|
| 996 |
+-------+
SELECT 1
Time: 0.032s |
Ok, I think it's clear to me now after skimming PG source - quals are not meant to be rechecked in case of pushed down aggregations, because if FDW says the pushdown is safe, there's no way to disentangle the returned aggregate result and discard the contributing rows which do not match quals. Instead, what needs to be done is to reject aggregation pushdown in the plan phase if the qual operator is not supported,here is an example for SQLite FDW. |
This allows Multicorn to correctly classify the quals it supports into remote and local conditions. In turn, this allows us to decide whether pushdown is achievable or not. Additionally, inquire Python FDW instance about the qual operators it supports.
This reverts commit 849bd2e.
WHERE
) clauses in combination with aggregations.COUNT(*)
CU-1z461e4