[
https://issues.apache.org/jira/browse/PHOENIX-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-3328:
--
Assignee: William Yang
> Skip scan optimization failed for multi pk colu
[
https://issues.apache.org/jira/browse/PHOENIX-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-3328:
--
Fix Version/s: 4.8.2
4.9.0
> Skip scan optimization failed for multi
value of PK1 in the RHS of OR is smaller than the LHS', but range of PK2 is
greater than the left. I think it's OK for us to be able to handle the first
PK only.
> Skip scan optimization failed for multi pk columns
> --
>
> Key
Ted:
The email in my 'send box' has the attachment, but the email received didn't. I
don't why.
I filed a jira, see https://issues.apache.org/jira/browse/PHOENIX-3328.
I only add one test case for this. We already have some UT and IT for other
scenarios that WHERE clause shouldn't be optimized
[
https://issues.apache.org/jira/browse/PHOENIX-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Yang updated PHOENIX-3328:
--
Attachment: PHOENIX-3328.patch
> Skip scan optimization failed for multi pk colu
William Yang created PHOENIX-3328:
-
Summary: Skip scan optimization failed for multi pk columns
Key: PHOENIX-3328
URL: https://issues.apache.org/jira/browse/PHOENIX-3328
Project: Phoenix
William,
Yes, PHOENIX-1801 is a good one too. IMHO, we should do that work in the
calcite branch where we can leverage the cost based optimizer framework in
Calcite.
Thanks,
James
On Sat, Sep 24, 2016 at 7:36 AM, Ted Yu wrote:
> William:
> I don't see attachment in your
William:
I don't see attachment in your original email.
Mind sharing the JIRA number once you open the JIRA (I assume the patch
would be attached there) ?
Thanks
On Thu, Sep 22, 2016 at 9:24 PM, William wrote:
> Hi all,
>This is a simple scenario, there are two tables:
>
OK James, I'll do this tomorrow and have a look at those tickets.
Also, I am planning to do this,
https://issues.apache.org/jira/browse/PHOENIX-1801. I'd like to support
intersect and union scenario first, then sort union.
Actually the QueryOptimizer doesn't 'choose' the appropriate index
Great find, William! Please file a JIRA with a test case and a patch, and
we'll get this reviewed and committed.
If you're interested and have time, there are a couple more issues related
to skip scan that you could take a look at too: PHOENIX-1439, PHOENIX-307,
and PHOENIX-1193.
Thanks,
James
Hi all,
This is a simple scenario, there are two tables:
create table t1 (pk integer primary key, a integer);
create table t2 (pk1 integer not null, pk2 integer not null, a integer
constraint pk primary key (pk1, pk2));
Do the following selects:
1. explain select * from t1 where
11 matches
Mail list logo