[jira] [Comment Edited] (PHOENIX-4002) Document FETCH NEXT| n ROWS from Cursor
[
https://issues.apache.org/jira/browse/PHOENIX-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16189663#comment-16189663
]
Jacobo Coll edited comment on PHOENIX-4002 at 10/3/17 12:46 PM:
Hi,
I was testing the new cursor functionality, and I have seen that the grammar
does not match with the examples at http://phoenix.apache.org/cursors.html
Instead of "{{OPEN CURSOR cursorName}}" should be "{{OPEN cursorName}}"
Also, "{{DECLARE CURSOR cursorName FOR selectStatement}}" should be "{{DECLARE
cursorName CURSOR FOR selectStatement}}"
was (Author: jacollmo):
Hi,
I was testing the new cursor functionality, and I have seen that the grammar
does not match with the examples at http://phoenix.apache.org/cursors.html
Instead of "{{OPEN CURSOR cursorName}}" should be "{{OPEN cursorName}}"
Also, "{{DECLARE CURSOR cursorName FOR selectStatemen}}t" should be "{{DECLARE
cursorName CURSOR FOR selectStatement}}"
> Document FETCH NEXT| n ROWS from Cursor
> ---
>
> Key: PHOENIX-4002
> URL: https://issues.apache.org/jira/browse/PHOENIX-4002
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Biju Nair
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4002-WIP.PATCH
>
>
> Now that PHOENIX-3572 is resolved and released, we need to add documentation
> for this new functionality on our website. For directions on how to do that,
> see http://phoenix.apache.org/building_website.html. I'd recommend adding a
> new top level page linked off of our Features menu that explains from a users
> perspective how to use it, and also updating our reference grammar here
> (which is derived from content in phoenix.csv):
> http://phoenix.apache.org/language/index.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4002) Document FETCH NEXT| n ROWS from Cursor
[
https://issues.apache.org/jira/browse/PHOENIX-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16189663#comment-16189663
]
Jacobo Coll commented on PHOENIX-4002:
--
Hi,
I was testing the new cursor functionality, and I have seen that the grammar
does not match with the examples at http://phoenix.apache.org/cursors.html
Instead of "{{OPEN CURSOR cursorName}}" should be "{{OPEN cursorName}}"
Also, "{{DECLARE CURSOR cursorName FOR selectStatemen}}t" should be "{{DECLARE
cursorName CURSOR FOR selectStatement}}"
> Document FETCH NEXT| n ROWS from Cursor
> ---
>
> Key: PHOENIX-4002
> URL: https://issues.apache.org/jira/browse/PHOENIX-4002
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Biju Nair
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4002-WIP.PATCH
>
>
> Now that PHOENIX-3572 is resolved and released, we need to add documentation
> for this new functionality on our website. For directions on how to do that,
> see http://phoenix.apache.org/building_website.html. I'd recommend adding a
> new top level page linked off of our Features menu that explains from a users
> perspective how to use it, and also updating our reference grammar here
> (which is derived from content in phoenix.csv):
> http://phoenix.apache.org/language/index.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-3328) Optimize ORed leading pk column range comparisions to SkipScan
[
https://issues.apache.org/jira/browse/PHOENIX-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15588305#comment-15588305
]
Jacobo Coll commented on PHOENIX-3328:
--
I am having the same problem in Phoenix 4.7. Is it possible to include this
patch in the 4.7.1?
> Optimize ORed leading pk column range comparisions to SkipScan
> --
>
> Key: PHOENIX-3328
> URL: https://issues.apache.org/jira/browse/PHOENIX-3328
> Project: Phoenix
> Issue Type: Bug
>Reporter: William Yang
>Assignee: William Yang
>Priority: Minor
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3328.patch
>
>
> {code:sql}
> 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));
> explain select * from t1 where (pk > 10 and pk < 20) or (pk > 30 and pk < 40);
> explain select * from t2 where (pk1 > 10 and pk1 < 20) or (pk1 > 30 and pk1 <
> 40);
> {code}
> The first SELECT statement will use skip scan filter for two ranges, so as
> the second one. But actually the WhereOptimizer failed doing so and using a
> full table scan instead. This happens for tables have multi PK columns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2548) Local Indexing Not Looks Like Working As Expected
[
https://issues.apache.org/jira/browse/PHOENIX-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15549236#comment-15549236
]
Jacobo Coll commented on PHOENIX-2548:
--
Such a great news!
Would this work also if the third filter is not part of the primary key?
Something like
{code:sql}
select devicename from devicedim_type1 where IPADDRESS = 'ccd' and devicename =
'abc' and macaddress = 'afg';
{code}
> Local Indexing Not Looks Like Working As Expected
> -
>
> Key: PHOENIX-2548
> URL: https://issues.apache.org/jira/browse/PHOENIX-2548
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.5.2
>Reporter: Gokhan Cagrici
>Assignee: Rajeshbabu Chintaguntla
>Priority: Critical
> Labels: verify
> Fix For: 4.9.0
>
>
> Hi,
> We are accessing this table using a variety of different WHERE clauses and
> for each of them, we are trying to create an appropriate index to avoid full
> table scan. Since there is going to be almost 20 indexes, we tried to proceed
> with local indexing since there will be a lot of writes.
> Here is the table definition:
> CREATE TABLE DEVICEDIM_TYPE1 (
> TENANT_ID VARCHAR NOT NULL,
> DEVICE_TYPE1_KEY BIGINT NOT NULL,
> CLASSNAME VARCHAR(64),
> DAY_IN_MONTH SMALLINT,
> MONTH_NUMBER SMALLINT,
> QUARTER_NUMBER SMALLINT,
> YEAR SMALLINT,
> WEEK_NUMBER SMALLINT,
> YEAR_FOR_WEEK SMALLINT,
> HOUR SMALLINT,
> MINUTE SMALLINT,
> IPADDRESS VARCHAR(50),
> DEVICENAME VARCHAR(255),
> MACADDRESS VARCHAR(30),
> CONSTRAINT PK PRIMARY KEY (TENANT_ID, DEVICE_TYPE1_KEY)
> ) SALT_BUCKETS=4, COMPRESSION='GZ', VERSIONS=1, MULTI_TENANT=TRUE;
> And here is the index:
> create local index gokhan_ix2 on devicedim_type1 (devicename, macaddress)
> Now if I execute this:
> explain select devicename from devicedim_type1 where tenant_id = 'ccd' and
> devicename = 'abc' and macaddress = 'afg'
> Here is the output:
> CLIENT 4-CHUNK PARALLEL 4-WAY RANGE SCAN OVER DEVICEDIM_TYPE1 [0,'ccd']
> SERVER FILTER BY (DEVICENAME = 'abc' AND MACADDRESS = 'afg')
> SERVER 100 ROW LIMIT
> CLIENT 100 ROW LIMIT
> I was expecting the index to be used. Am I wrong?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2548) Local Indexing Not Looks Like Working As Expected
[ https://issues.apache.org/jira/browse/PHOENIX-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15546130#comment-15546130 ] Jacobo Coll commented on PHOENIX-2548: -- Hi there, Is there any progress on this? I had also the same problem, and I was expecting the index to be used. I don't see much problem, since the data is already there, you only have to add some more filters. Is not like a global index, where you don't have all the data. > Local Indexing Not Looks Like Working As Expected > - > > Key: PHOENIX-2548 > URL: https://issues.apache.org/jira/browse/PHOENIX-2548 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.5.2 >Reporter: Gokhan Cagrici >Assignee: Rajeshbabu Chintaguntla >Priority: Critical > Labels: verify > Fix For: 4.9.0 > > > Hi, > We are accessing this table using a variety of different WHERE clauses and > for each of them, we are trying to create an appropriate index to avoid full > table scan. Since there is going to be almost 20 indexes, we tried to proceed > with local indexing since there will be a lot of writes. > Here is the table definition: > CREATE TABLE DEVICEDIM_TYPE1 ( > TENANT_ID VARCHAR NOT NULL, > DEVICE_TYPE1_KEY BIGINT NOT NULL, > CLASSNAME VARCHAR(64), > DAY_IN_MONTH SMALLINT, > MONTH_NUMBER SMALLINT, > QUARTER_NUMBER SMALLINT, > YEAR SMALLINT, > WEEK_NUMBER SMALLINT, > YEAR_FOR_WEEK SMALLINT, > HOUR SMALLINT, > MINUTE SMALLINT, > IPADDRESS VARCHAR(50), > DEVICENAME VARCHAR(255), > MACADDRESS VARCHAR(30), > CONSTRAINT PK PRIMARY KEY (TENANT_ID, DEVICE_TYPE1_KEY) > ) SALT_BUCKETS=4, COMPRESSION='GZ', VERSIONS=1, MULTI_TENANT=TRUE; > And here is the index: > create local index gokhan_ix2 on devicedim_type1 (devicename, macaddress) > Now if I execute this: > explain select devicename from devicedim_type1 where tenant_id = 'ccd' and > devicename = 'abc' and macaddress = 'afg' > Here is the output: > CLIENT 4-CHUNK PARALLEL 4-WAY RANGE SCAN OVER DEVICEDIM_TYPE1 [0,'ccd'] > SERVER FILTER BY (DEVICENAME = 'abc' AND MACADDRESS = 'afg') > SERVER 100 ROW LIMIT > CLIENT 100 ROW LIMIT > I was expecting the index to be used. Am I wrong? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
