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

[YSQL] Bitmap Scan Crash with no columns required from a NLJ relation #21980

Closed
1 task done
timothy-e opened this issue Apr 15, 2024 · 0 comments
Closed
1 task done
Assignees
Labels
area/ysql Yugabyte SQL (YSQL) kind/bug This issue is a bug priority/medium Medium priority issue

Comments

@timothy-e
Copy link
Contributor

timothy-e commented Apr 15, 2024

Jira Link: DB-10901

Description

explain /*+ NestLoop(c ns) SeqScan(c) BitmapScan(ns) */ 
select c.relname from pg_class c, pg_namespace ns
where ns.oid = c.relnamespace and c.relname > 'a';
                                        QUERY PLAN
-------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.30..467.23 rows=100 width=64)
   ->  Seq Scan on pg_class c  (cost=0.00..102.50 rows=100 width=68)
         Storage Filter: (relname > 'a'::name)
   ->  YB Bitmap Table Scan on pg_namespace ns  (cost=0.30..4.31 rows=1 width=4)
         ->  Bitmap Index Scan on pg_namespace_oid_index  (cost=0.00..0.30 rows=1 width=0)
               Index Cond: (oid = c.relnamespace)
(6 rows)

Running the query results in a crash

explain analyze /*+ NestLoop(c ns) SeqScan(c) BitmapScan(ns) */  
select c.relname from pg_class c, pg_namespace ns
where ns.oid = c.relnamespace and c.relname > 'a';

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

  • I confirm this issue does not contain any sensitive information.
@timothy-e timothy-e added area/ysql Yugabyte SQL (YSQL) status/awaiting-triage Issue awaiting triage labels Apr 15, 2024
@timothy-e timothy-e self-assigned this Apr 15, 2024
@yugabyte-ci 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
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
area/ysql Yugabyte SQL (YSQL) kind/bug This issue is a bug priority/medium Medium priority issue
Projects
None yet
Development

No branches or pull requests

2 participants