-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[YSQL] Bitmap Scan Crash with no columns required from a NLJ relation #21980
Labels
Comments
timothy-e
added
area/ysql
Yugabyte SQL (YSQL)
status/awaiting-triage
Issue awaiting triage
labels
Apr 15, 2024
yugabyte-ci
added
kind/bug
This issue is a bug
priority/medium
Medium priority issue
and removed
status/awaiting-triage
Issue awaiting triage
labels
Apr 15, 2024
1 task
timothy-e
added a commit
that referenced
this issue
Apr 19, 2024
Summary: Bitmap scans try to optimize cases where the actual tuples are not required by avoiding fetching the rows from the table. This was added in PG to support the COUNT(*) use case, but would also optimize returning system attributes that aren't stored in DocDB. In both of these cases, we already have everything we need locally: an exact number of ybctids, or the system attributes. Sending a request is a waste of time. However, there are a few edge cases / optimization to this that make it a bit more complicated. For now, disable this optimisation so that we can do it right later, at a priority that makes sense. That follow up is tracked by #22044 Jira: DB-10901 Test Plan: ``` ./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressYbBitmapScans' ``` Reviewers: amartsinchyk, tnayak Reviewed By: amartsinchyk Subscribers: yql Tags: #jenkins-ready Differential Revision: https://phorge.dev.yugabyte.com/D34137
timothy-e
added a commit
that referenced
this issue
Apr 29, 2024
…ap Table Scan Summary: Original commit: 03fd372 / D34137 Bitmap scans try to optimize cases where the actual tuples are not required by avoiding fetching the rows from the table. This was added in PG to support the COUNT(*) use case, but would also optimize returning system attributes that aren't stored in DocDB. In both of these cases, we already have everything we need locally: an exact number of ybctids, or the system attributes. Sending a request is a waste of time. However, there are a few edge cases / optimization to this that make it a bit more complicated. For now, disable this optimisation so that we can do it right later, at a priority that makes sense. That follow up is tracked by #22044 Jira: DB-10901 Test Plan: ``` ./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressYbBitmapScans' ``` Reviewers: amartsinchyk, tnayak Reviewed By: amartsinchyk Subscribers: yql Tags: #jenkins-ready Differential Revision: https://phorge.dev.yugabyte.com/D34335
svarnau
pushed a commit
that referenced
this issue
May 25, 2024
Summary: Bitmap scans try to optimize cases where the actual tuples are not required by avoiding fetching the rows from the table. This was added in PG to support the COUNT(*) use case, but would also optimize returning system attributes that aren't stored in DocDB. In both of these cases, we already have everything we need locally: an exact number of ybctids, or the system attributes. Sending a request is a waste of time. However, there are a few edge cases / optimization to this that make it a bit more complicated. For now, disable this optimisation so that we can do it right later, at a priority that makes sense. That follow up is tracked by #22044 Jira: DB-10901 Test Plan: ``` ./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressYbBitmapScans' ``` Reviewers: amartsinchyk, tnayak Reviewed By: amartsinchyk Subscribers: yql Tags: #jenkins-ready Differential Revision: https://phorge.dev.yugabyte.com/D34137
ZhenYongFan
pushed a commit
to ZhenYongFan/yugabyte-db
that referenced
this issue
Jun 15, 2024
… YB Bitmap Table Scan Summary: Original commit: 03fd372 / D34137 Bitmap scans try to optimize cases where the actual tuples are not required by avoiding fetching the rows from the table. This was added in PG to support the COUNT(*) use case, but would also optimize returning system attributes that aren't stored in DocDB. In both of these cases, we already have everything we need locally: an exact number of ybctids, or the system attributes. Sending a request is a waste of time. However, there are a few edge cases / optimization to this that make it a bit more complicated. For now, disable this optimisation so that we can do it right later, at a priority that makes sense. That follow up is tracked by yugabyte#22044 Jira: DB-10901 Test Plan: ``` ./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressYbBitmapScans' ``` Reviewers: amartsinchyk, tnayak Reviewed By: amartsinchyk Subscribers: yql Tags: #jenkins-ready Differential Revision: https://phorge.dev.yugabyte.com/D34335
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Jira Link: DB-10901
Description
Running the query results in a crash
because it expected a non-null tuple and got a null one.
The bitmap scan yielded a all-null tuple because it (correctly) determined that the actual value of its tuples wasn't relevant. Since all of its conditions were satisfied by the Bitmap Index Scan, there's no need to fetch from the main table.
Issue Type
kind/bug
Warning: Please confirm that this issue does not contain any sensitive information
The text was updated successfully, but these errors were encountered: