phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-5116) DistinctPrefixFilterIT fails.
Date Thu, 31 Jan 2019 08:06:00 GMT


Hadoop QA commented on PHOENIX-5116:

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment
  against master branch at commit 3a4a727b6d07dada726fc75d3061a15b93ae9789.
  ATTACHMENT ID: 12957021

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include any new or modified
                        Please justify why no new tests are needed for this patch.
                        Also please list what manual steps were performed to verify this patch.

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of
javac compiler warnings.

    {color:red}-1 release audit{color}.  The applied patch generated 1 release audit warnings
(more than the master's current 0 warnings).

    {color:green}+1 lineLengths{color}.  The patch does not introduce lines longer than 100

     {color:red}-1 core tests{color}.  The patch failed these unit tests:

Test results:
Release audit warnings:
Console output:

This message is automatically generated.

> DistinctPrefixFilterIT fails.
> -----------------------------
>                 Key: PHOENIX-5116
>                 URL:
>             Project: Phoenix
>          Issue Type: Task
>    Affects Versions: 4.15.0
>            Reporter: Lars Hofhansl
>            Priority: Major
>             Fix For: 4.15.0
>         Attachments: 5116-master.txt, 5116-master.txt, 5116.txt
> Caused by this scenario outlined on PHOENIX-5109:
> {quote}
> This just does not end. Now there's a special case for the following:
> *     compound key of VARCHAR
> *     SELECT DISTINCT <prefix of the key>
> *     Salting is enabled
> *     There is a local index on an unrelated column
> Now Phoenix selects a full local index scan, which is heuristically less efficient...
I think.
> The problem is that there are cases where a plan for a salted table nonetheless gets
a key range that is not salted - does not have the salt range in it. That throws the logic
off in this case.
> {quote}

This message was sent by Atlassian JIRA

View raw message