DB-12351 Remove the pre-scan of IndexPrefixIteratorMode on HBase

[msirek]

Short Description

Removes a costly pre-scan to find the first row in the table before a IndexPrefixIteratorMode scan. This is impacting the performance of livewire queries.

Long Description

DB-11930 fixed some execution issues in IndexPrefixIteratorMode table scans. One problem it tried to fix is a missing qualifier in the main TableScanOperation. Since operation tree deserialization sometimes deserializes items from a map keyed off of the target result set of the operation, the null qualifiersField in the IndexPrefixIteratorOperation was picked up as the qualifiers for the main TableScanOperation since they share the same target result set number, effectively removing the qualifiers. DB-11930 fixed it by writing the same qualifiersField to the IndexPrefixIteratorOperation as the TableScanOperation, but then added a flag to skip building of the qualifiers, since we want to retrieve the very first row. This was problematic because the flag was reset to false right after getNonSIScan was called, but needed to be reset after buildDataSet to ensure it was properly used. The effect is that the qualifier is also applied during the scan to find the first row. It may end up scanning through the whole table in control mode, if none of the rows qualify.

Really, we don't need to read the first row to get the DataValueDescriptor of the first index column. A null DVD is already built for us in the template row. So, the fix is to remove the scan for the first row entirely, for HBase platforms. For the mem platform, which still needs to collect the first column values, the scan is still done.

How to test

Run the following on iotdev03. The job should show up in the spark UI right away, and it should take minutes, not hours, to run:

set session_property favorIndexPrefixIteration=TRUE;
set session_property alwaysAllowIndexPrefixIteration=true;

EXPLAIN SELECT count(*) from
(SELECT FULL_TAG_NAME, START_TS, END_TS,
AVG(TIME_WEIGHTED_VALUE) TIME_WEIGHTED_VALUE,
MIN(TIME_WEIGHTED_VALUE) MIN_VALUE,
MAX(TIME_WEIGHTED_VALUE) MAX_VALUE,
MIN(VALUE_STATE) VALUE_STATE,
MIN(QUALITY) QUALITY
FROM
(
SELECT
FULL_TAG_NAME,
SPLICE.TIMESTAMPSNAPTOINTERVAL("START_TS",2,10) START_TS,
SPLICE.TIMESTAMPSNAPTOINTERVAL("START_TS",2,10) + 10 minute END_TS,
TIME_WEIGHTED_VALUE,
VALUE_STATE,
QUALITY
FROM OCI2.RESAMPLED_DATA_1M --splice-properties index=null
WHERE START_TS >= (timestamp('2020-01-01 12:00:00') - 1 minute) AND START_TS < timestampadd(SQL_TSI_FRAC_SECOND, -1000, timestamp('2020-01-01 12:00:00'))
)
GROUP BY 1,2,3);

[msirek]

jenkins please test branch @dbaas3.1,skipTestsLongerThan2Minutes

[cloudspliceci]

TEST FAILED
http://nexus.splicemachine.com:8080/job/spliceengine-PR/job/Splice-PR-Branch/3373/

[msirek]

jenkins please test branch @dbaas3.1,skipTestsLongerThan2Minutes

[cloudspliceci]

TEST FAILED
http://nexus.splicemachine.com:8080/job/spliceengine-PR/job/Splice-PR-Branch/3379/

[msirek]

jenkins please test branch @cdh6.3.0,skipTestsLongerThan2Minutes

[cloudspliceci]

TEST SUCCEEDED +1

[ascend1]

Great fix!

In description, this sounds strange, though:

Since operation tree deserialization sometimes deserializes items from a map based on the target result set of the operation, the null qualifiersField in the IndexPrefixIteratorOperation was picked up as the qualifiers for the main TableScanOperation, effectively removing the qualifiers.

It sounds like a problem we should fix. Is that right?

[msirek]

Great fix!

In description, this sounds strange, though:

Since operation tree deserialization sometimes deserializes items from a map based on the target result set of the operation, the null qualifiersField in the IndexPrefixIteratorOperation was picked up as the qualifiers for the main TableScanOperation, effectively removing the qualifiers.

It sounds like a problem we should fix. Is that right?

@ascend1 It seems to be by design. There is an assumption in the code that each SpliceOperation will have a different target result set number. That's not an unreasonable assumption, to assume each operation is independent and works on a stream of rows. This is a little different than what IndexPrefixIteratorOperation does. It is more like a modifier which builds an HBase filter for the underlying TableScan based on runtime values of start/stop keys. In the case of mem platform, it actually does iteratively apply the underlying TableScan, but it's still more like an Operation modifier than a true independent operation. Let me see if I can locate the code that serializes based on result set number and open a Jira to investigate a better way to do this.

Created DB-12376 for this.

[carolp-503]

+1