[
https://issues.apache.org/jira/browse/PHOENIX-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14123464#comment-14123464
]
Kyle Buzsaki commented on PHOENIX-1211:
---------------------------------------
Something isn't adding up then.
I altered the test to be the following:
ddl / schema (just added another pk column):
{code}
CREATE TABLE tempTableWithCompositePK (
col0 INTEGER NOT NULL,
col1 INTEGER NOT NULL,
col2 INTEGER NOT NULL,
col3 INTEGER NOT NULL,
col4 INTEGER
CONSTRAINT pk PRIMARY KEY (col0, col1, col2, col3))
SALT_BUCKETS=4
// produces
[BINARY(1) NOT NULL, 4 * INTEGER NOT NULL] // salted with col0, col1, col2,
col3 as pks, col4 as kv
{code}
where clause:
{code}
WHERE (col0, col1) in ((2, 3), (3, 4), (4, 5)) and (col2 = 5 or col2 = 6)
{code}
Here, if we should ignore certain indices of the position array, then I would
expect the slots/position/slotSpan to all have length 4: 1 for the salt byte,
and 1 for each of the pks used in the where clause. It should look something
like this:
{code}
slots: | salt | col0+col1 | empty | col2 |
slotSpan: | 0 | 1 | empty | 0 |
position: | 0 | 0 | empty | 0 |
{code}
But running the code as it is now, that's not the skip scan that we get.
Instead we get this:
{code}
slots: | salt | col0+col1 | col2 |
slotSpan: | 0 | 1 | 0 |
position: | 0 | 0 | 0 |
{code}
For reference, this is what the slots list contains:
{code}
| salt | col0 and col1 | col2 |
+------+----------------------------------+------------------+
| 0x00 | \x80\x00\x00\x02\x80\x00\x00\x03 | \x80\x00\x00\x05 |
| 0x01 | \x80\x00\x00\x03\x80\x00\x00\x04 | \x80\x00\x00\x06 |
| 0x02 | \x80\x00\x00\x04\x80\x00\x00\x05 |
| 0x03 |
{code}
The way things are now, there aren't any "empty slots" or "holes" to account
for the extra span. This means that incrementing the i and j variables as I
described earlier (adjusted the numbers for this particular skip scan's
members):
bq. If i = 1 and we perform the following increment: {code} i += slotSpan[i] +
1; {code} then i is now 3, which is out of bounds of the position array. On
top of that, we've completely skipped past index 2, and it seems like we'll
never use it.
will cause the skip scan to get messed up.
> Use skip scan when row value constructor uses leading row key columns
> ----------------------------------------------------------------------
>
> Key: PHOENIX-1211
> URL: https://issues.apache.org/jira/browse/PHOENIX-1211
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Kyle Buzsaki
> Attachments: PHOENIX-1211-diff.patch
>
>
> We currently only use a skip scan for a row value constructor equality or in
> list expression is fully qualified. We can fairly easily use it when only
> some of the leading pk columns are used.
> For example:
> {code}
> WHERE (a,b) IN ((1,2),(3,4))
> {code}
> If the PK is (a,b,c), we can still use a skip scan. We need to pass through
> the slotSpan array in this case too, to the SkipScanFilter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
