[ 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)