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.

Sign up for GitHub

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

Jump to bottom

sql: optimize = ANY like IN #13593

Closed
knz opened this issue Feb 15, 2017 · 2 comments
Closed

sql: optimize = ANY like IN #13593

knz opened this issue Feb 15, 2017 · 2 comments
Labels
A-sql-optimizer SQL logical planning and optimizations. C-performance Perf of queries or internals. Solution not expected to change functional behavior.
Milestone
2.1

Comments

@knz
Copy link
Contributor

knz commented Feb 15, 2017 •
edited
Loading

Once arrays are supported we run into queries that select specific values with WHERE s = ANY([a,b,c]) instead of s IN (a,b,c).

We need to support them "just as well" i.e. generate the corresponding index constraints and ultimately KV lookup spans.

For reference, in pg all the IN expressions are converted to = ANY() internally, and only the latter refines index selection / point lookups.

Reported / detected in #13358.
@knz knz added C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) C-performance Perf of queries or internals. Solution not expected to change functional behavior. labels Feb 15, 2017
@petermattis petermattis mentioned this issue Feb 15, 2017
Closed
7 tasks
@knz knz mentioned this issue Feb 15, 2017
Closed
@tlvenn
Copy link
Contributor

tlvenn commented Feb 18, 2017

Hi @cuongdo, I just wanted to emphasis that per the discussion in #13358, the usage of ANY is not as exotic as one may think and many ORMs will favour it over the more conventional IN syntax.

So this should impact the overall performance big picture on the read side of things.

@petermattis petermattis added this to the Later milestone Feb 23, 2017
@tamird tamird modified the milestones: 1.1, Later Apr 19, 2017
@tamird tamird removed the 1.0-maybe label Apr 19, 2017
@cuongdo cuongdo modified the milestones: 1.2, 1.1 Aug 22, 2017
@bdarnell bdarnell modified the milestones: 2.0, 2.1 Feb 8, 2018
@knz knz added A-sql-optimizer SQL logical planning and optimizations. and removed C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) labels May 9, 2018
@andy-kimball
Copy link
Contributor

Like Postgres, the cost-based optimizer maps IN to ANY, so closing this as "Fixed".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-sql-optimizer SQL logical planning and optimizations. C-performance Perf of queries or internals. Solution not expected to change functional behavior.
Projects
None yet
Milestone
2.1
Development

No branches or pull requests
7 participants
@bdarnell @knz @tamird @cuongdo @tlvenn @petermattis @andy-kimball