Skip to content
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

Limit should not be pushed down if there are unconverted restrictions #291

Closed
kaidaguerre opened this issue Mar 1, 2023 · 0 comments · Fixed by #292
Closed

Limit should not be pushed down if there are unconverted restrictions #291

kaidaguerre opened this issue Mar 1, 2023 · 0 comments · Fixed by #292

Comments

@kaidaguerre
Copy link
Contributor

We only push down the limit to the plugin if all the where clauses are for key columns (with a supported operator). In this case, tags is not a key column so we should not be pushing down the limit.

Postgres passes the where clauses as restrictions which our FDW attempts to evaluate and convert into a Qual struct which is passed to the plugin. Sometimes we are unable to do this conversion. That is the case here:

SELECT region, instance_id, tags->>'Name' as name,  metadata_options['HttpEndpoint'] as HttpEndpoint, metadata_options['HttpTokens'] as HttpTokens FROM aws.aws_ec2_instance WHERE tags->>'Name' LIKE '%web%' LIMIT 1;

we cannot (currently) convert the Jsonb addressing syntax from a Postgres restriction into a Qual.

The limit pushdown logic does not take this into account, it just checks for successfully converted quals, so we are pushing down
the limit even though there is a non-key column where clause.

The fix is to update the pushdown logic to not pushdown if there are any unconverted restrictions. This will be in the upcoming release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant