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
anti-select uses full scan #7449
Comments
Initial thought is, why should it use a hash? The result of the select itself is (almost) the complete column, so we basically have to go through it anyway. |
My reasoning (ignoring NULLs) was: use a normal point select (with the hash) to find the value, and then you just need to return the original input except that one. It's true that you still need to go through all tuples, but without accessing the heap for all of them. |
Ie a negative candidate list
Niels
…On 26 January 2024 17:16:20 CET, Roberto Cornacchia ***@***.***> wrote:
My reasoning (ignoring NULLs) was: use a normal point select (with the hash) to find the value, and then you just need to return the original input except that one.
--
Reply to this email directly or view it on GitHub:
#7449 (comment)
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
|
Describe the bug
On a column that has a persistent hash, anti-select (and anti-join) resorts to full scan.
To Reproduce
Create a column with unique values
Test a point select :
The point select uses the hash table:
Test a point anti-select:
The point anti-select uses a full scan:
Expected behavior
Use the existing hash.
Software versions
The text was updated successfully, but these errors were encountered: