phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samarth Jain (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4265) NPE when hinting index on table with ROW_TIMESTAMP
Date Tue, 03 Oct 2017 09:06:02 GMT


Samarth Jain commented on PHOENIX-4265:

I am slightly puzzled by this piece of code in WhereOptimizer:

for (int i = 0; i < 2; i++) {
            List<Expression> group = Lists.newArrayList();
            for (Expression expression : candidates) {
                PDataType type = expression.getDataType();
                group.add(LiteralExpression.newConstant(type.getSampleValue(), type));

The sample values are generated using a random generator. And then they are eventually used
for pushing down key expressions into scan by using them in an InListExpression:

Expression testExpression = InListExpression.create(Lists.newArrayList(lhs, firstRhs, secondRhs),
false, context.getTempPtr(), context.getCurrentTable().getTable().rowKeyOrderOptimizable());
            remaining = pushKeyExpressionsToScan(context, statement, testExpression);

When using row timestamp, these random values could result in invalid timestamp range causing
the query to randomly fail with error like below:

java.lang.IllegalArgumentException: Timestamp cannot be negative. minStamp:-2644630825337824141,
	at org.apache.phoenix.compile.ScanRanges.getAscTimeRange(
	at org.apache.phoenix.compile.ScanRanges.getRowTimestampColumnRange(
	at org.apache.phoenix.compile.ScanRanges.create(
	at org.apache.phoenix.compile.WhereOptimizer.pushKeyExpressionsToScan(
	at org.apache.phoenix.compile.WhereOptimizer.pushKeyExpressionsToScan(
	at org.apache.phoenix.compile.WhereOptimizer.getKeyExpressionCombination(
	at org.apache.phoenix.compile.QueryCompiler.getKeyExpressionCombinations(
	at org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(
	at org.apache.phoenix.compile.QueryCompiler.compileSelect(
	at org.apache.phoenix.compile.QueryCompiler.compile(
	at org.apache.phoenix.optimize.QueryOptimizer.addPlan(
	at org.apache.phoenix.optimize.QueryOptimizer.getHintedQueryPlan(
	at org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(
	at org.apache.phoenix.optimize.QueryOptimizer.optimize(
	at org.apache.phoenix.optimize.QueryOptimizer.optimize(
	at org.apache.phoenix.jdbc.PhoenixStatement$
	at org.apache.phoenix.jdbc.PhoenixStatement$
	at org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(
	at org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(
	at org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(
	at org.apache.phoenix.end2end.UpsertSelectIT.testCodecUsedForRowTimestamp(

[~jamestaylor] - are these random values are only used for the purpose of generating all applicable
plans? And if so, would it be ok to make sure that the sampled values returned are positive?

> NPE when hinting index on table with ROW_TIMESTAMP
> --------------------------------------------------
>                 Key: PHOENIX-4265
>                 URL:
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: James Taylor
> See email discussion here:
> I'm not able to repro with this unit test:
> {code}
>     @Test
>     public void testIndexHintOnTableWithRowTimestamp() throws Exception {
>         Connection conn = DriverManager.getConnection(getUrl());
>         try {
>             conn.createStatement().execute("CREATE IMMUTABLE TABLE t1 (k1 TIMESTAMP not
null, k2 bigint not null, v bigint, constraint pk primary key (k1 row_timestamp,k2 ))");
>             conn.createStatement().execute("CREATE INDEX idx ON t1 (v)");
>             conn.createStatement().execute("SELECT /*+ INDEX(T1 IDX) */ K1,K2,V FROM
t1 WHERE v = 5");
>         } finally {
>             conn.close();
>         }
>     }
> {code}
> FYI, due to the inability to keep an index in sync when there's a ROW_TIMESTAMP column,
as of 4.12 we're disallowing the creation of mutable secondary indexes when a table has a
ROW_TIMESTAMP column. Usually, since the timestamp is part of the row key, the data table
can be declared IMMUTABLE. In this case, the index would still be allowed.

This message was sent by Atlassian JIRA

View raw message