[
https://issues.apache.org/jira/browse/PHOENIX-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14065651#comment-14065651
]
James Taylor commented on PHOENIX-1082:
---------------------------------------
Nice work, [~kbuzsaki]. The skip scan filter should not be used when there are
RVC unless it is fully qualified. This looks to be related to the other bug
that Samarth found (PHOENIX-1089). The WhereOptimizer needs to fold ANDed
columns into the RVC such that it's fully qualified (and if it's not, it
shouldn't be using the skip scan as the skip scan won't handle RVC correctly -
it doesn't know how to deal with them correctly).
Let me take a look and see if there's a quick fix.
> IN List of RVCs doesn't return all the rows when executed against a
> tenant-specific view for a multi-tenant table that is salted.
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-1082
> URL: https://issues.apache.org/jira/browse/PHOENIX-1082
> Project: Phoenix
> Issue Type: Bug
> Reporter: Samarth Jain
> Assignee: Samarth Jain
>
> {code}
> Table type - Multitenant and salted. Query - IN list of RVCs. Result - All
> rows not returned.
> Base table DDL - CREATE TABLE t (tenantId varchar(5) NOT NULL, pk2 varchar(5)
> NOT NULL, pk3 INTEGER NOT NULL, c1 INTEGER constraint pk primary key
> (tenantId,pk2,pk3)) MULTI_TENANT=true, SALT_BUCKETS=4
> Tenant View DDL - CREATE VIEW t_view (tenant_col VARCHAR) AS SELECT * FROM t
> Upserts:
> upsert into t_view (pk2, pk3, c1) values ('helo1', 1, 1)
> upsert into t_view (pk2, pk3, c1) values ('helo2', 2, 2)
> upsert into t_view (pk2, pk3, c1) values ('helo3', 3, 3)
> upsert into t_view (pk2, pk3, c1) values ('helo4', 4, 4)
> upsert into t_view (pk2, pk3, c1) values ('helo5', 5, 5)
> Query using tenant specific connection - select pk2, pk3 from t_view WHERE
> (pk2, pk3) IN ( ('helo3', 3), ('helo5', 5) ) ORDER BY pk2
> Result - Only one row returned - helo3, 3
> This has likely to do with salting because on removing SALT_BUCKETS=4 from
> the base table DDL all the expected rows are returned.
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
