[
https://issues.apache.org/jira/browse/KUDU-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-3384:
--------------------------------
Description:
Recently, a new DRS-level optimization for scan operations has been introduced
with changelist
[936d7edc4|https://github.com/apache/kudu/commit/936d7edc4e4b69d2e1f1dffc96760cb3fd57a934].
The newly introduced DRS-level optimization leads to scan failures when all of
the following turns true:
* all the primary key columns are of integer types
* the table has no hash partitioning
* the table contains a value with all primary key columns set to
{{INT\{x}_MAX}} correspondingly
* the scan request is to scan all the table's data
I suspect that some of the conditions above might be relaxed, but I have a test
case that reproduces the issue as described.
was:
Recently, a new DRS-level optimization for scan operations has been introduced
with changelist
[936d7edc4|https://github.com/apache/kudu/commit/936d7edc4e4b69d2e1f1dffc96760cb3fd57a934].
The newly introduced DRS-level optimization leads to scan failures when all of
the following turns true:
* all the primary key columns are of integer types
* the table has no hash partitioning
* the table contains a value with all primary key columns set to INT{x}_MAX
correspondingly
* the scan request is to scan all the table's data
I suspect that some of the conditions above might be relaxed, but I have a test
case that reproduces the issue as described.
> DRS-level scan optimization leads to failed scans
> -------------------------------------------------
>
> Key: KUDU-3384
> URL: https://issues.apache.org/jira/browse/KUDU-3384
> Project: Kudu
> Issue Type: Bug
> Components: tserver
> Affects Versions: 1.17.0
> Reporter: Alexey Serbin
> Priority: Major
>
> Recently, a new DRS-level optimization for scan operations has been
> introduced with changelist
> [936d7edc4|https://github.com/apache/kudu/commit/936d7edc4e4b69d2e1f1dffc96760cb3fd57a934].
> The newly introduced DRS-level optimization leads to scan failures when all
> of the following turns true:
> * all the primary key columns are of integer types
> * the table has no hash partitioning
> * the table contains a value with all primary key columns set to
> {{INT\{x}_MAX}} correspondingly
> * the scan request is to scan all the table's data
> I suspect that some of the conditions above might be relaxed, but I have a
> test case that reproduces the issue as described.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
