[jira] [Updated] (PHOENIX-5909) Table and index-level metrics for indexing coprocs
[ https://issues.apache.org/jira/browse/PHOENIX-5909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey Jacoby updated PHOENIX-5909: - Attachment: PHOENIX-5909-4.x-v1.patch > Table and index-level metrics for indexing coprocs > -- > > Key: PHOENIX-5909 > URL: https://issues.apache.org/jira/browse/PHOENIX-5909 > Project: Phoenix > Issue Type: Improvement >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby >Priority: Major > Fix For: 5.1.0, 4.16.0 > > Attachments: PHOENIX-5909-4.x-v1.patch > > Time Spent: 10m > Remaining Estimate: 0h > > For many of the metrics which the IndexRegionObserver and GlobalIndexChecker > coprocs expose, it would be useful to have them broken down by table or > index, in addition to the current aggregates by region server. This would > help us determine if, for example, a flood of read repairs was coming from > one particular index. > Thanks [~priyankporwal] for the feature suggestion. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-5841) When data columns get TTLed, we need inline index validation to publish a metric for this
[ https://issues.apache.org/jira/browse/PHOENIX-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swaroopa Kadam reassigned PHOENIX-5841: --- Assignee: Gokcen Iskender > When data columns get TTLed, we need inline index validation to publish a > metric for this > - > > Key: PHOENIX-5841 > URL: https://issues.apache.org/jira/browse/PHOENIX-5841 > Project: Phoenix > Issue Type: Improvement >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Attachments: PHOENIX-5841.4.x.001.patch, PHOENIX-5841.4.x.002.patch, > PHOENIX-5841.4.x.003.patch, PHOENIX-5841.master.001.patch, > PHOENIX-5841.master.002.patch, PHOENIX-5841.master.003.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > We do index writes as full row writes. This means all columns keep get > re-written to index and they have a current timestamp. > However, if there is a column that did not get updated for a long time (like > Created_By type of columns that don't change) index inline validation marks > these as "Index has extra columns". We need to publish an extra metric to > distinguish these cases since they are expected to be not matching rows. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-5890) Port PHOENIX-5799 to master
[ https://issues.apache.org/jira/browse/PHOENIX-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swaroopa Kadam reassigned PHOENIX-5890: --- Assignee: Swaroopa Kadam (was: Geoffrey Jacoby) > Port PHOENIX-5799 to master > --- > > Key: PHOENIX-5890 > URL: https://issues.apache.org/jira/browse/PHOENIX-5890 > Project: Phoenix > Issue Type: Improvement >Reporter: Geoffrey Jacoby >Assignee: Swaroopa Kadam >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-5912) Improve code coverage for the 'org.apache.phoenix.coprocessor.tasks' package
[ https://issues.apache.org/jira/browse/PHOENIX-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni reassigned PHOENIX-5912: - Assignee: Anjan Das > Improve code coverage for the 'org.apache.phoenix.coprocessor.tasks' package > > > Key: PHOENIX-5912 > URL: https://issues.apache.org/jira/browse/PHOENIX-5912 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.0.0, 4.15.0, 4.14.3 >Reporter: Chinmay Kulkarni >Assignee: Anjan Das >Priority: Major > Labels: phoenix-hardening, quality-improvement > Fix For: 5.1.0, 4.16.0 > > > Currently the instruction code coverage for this package is 42% and branch > coverage is 25%. Please see any latest build to confirm the code paths that > are uncovered in testing. > > Sample build : > [https://builds.apache.org/job/PreCommit-PHOENIX-Build/3873/artifact/phoenix-core/target/site/jacoco/index.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5884) Join query return empty result when filters for both the tables are present
[
https://issues.apache.org/jira/browse/PHOENIX-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated PHOENIX-5884:
-
Attachment: PHOENIX-5884.master.v4.patch
> Join query return empty result when filters for both the tables are present
> ---
>
> Key: PHOENIX-5884
> URL: https://issues.apache.org/jira/browse/PHOENIX-5884
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.0
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Attachments: PHOENIX-5884.master.v2.patch,
> PHOENIX-5884.master.v3.patch, PHOENIX-5884.master.v4.patch,
> PHOENIX-5884_v1.patch
>
>
> Let's assume DDL to be same for both the tables involved in a join
> {code}
> CREATE TABLE LeftTable (id1 CHAR(6) NOT NULL,id2 VARCHAR(22) NOT
> NULL,id3 VARCHAR(12) NOT NULL,id4 CHAR(2) NOT NULL,id5 CHAR(6)
> NOT NULL, id6 VARCHAR(200) NOT NULL,id7 VARCHAR(50) NOT NULL,ts
> TIMESTAMP ,CONSTRAINT PK_JOIN_AND_INTERSECTION_TABLE PRIMARY
> KEY(id1,id2,id3,id4,id5,id6,id7))
> {code}
> Following query return right results
> {code}
> SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
> m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and
> m.ts = r.ts where r.id1 IN ('201904','201905') and r.id2 = 'ID2_VAL' and
> r.id3 IN ('ID3_VAL','ID3_VAL2')
> {code}
> but When to optimize the query, filters for the left table are also added ,
> query returned empty result . Though the filters are based on join condition
> so semantically above query and below query should be same.
> {code}
> SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
> m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and
> m.ts = r.ts where m.id1 IN ('201904','201905') and r.id1 IN
> ('201904','201905') and r.id2 = 'ID2_VAL' and m.id3 IN
> ('ID3_VAL','ID3_VAL2') and r.id3 IN ('ID3_VAL','ID3_VAL2')
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5884) Join query return empty result when filters for both the tables are present
[
https://issues.apache.org/jira/browse/PHOENIX-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated PHOENIX-5884:
-
Attachment: (was: PHOENIX-5884.master.v4.patch)
> Join query return empty result when filters for both the tables are present
> ---
>
> Key: PHOENIX-5884
> URL: https://issues.apache.org/jira/browse/PHOENIX-5884
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.0
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Attachments: PHOENIX-5884.master.v2.patch,
> PHOENIX-5884.master.v3.patch, PHOENIX-5884_v1.patch
>
>
> Let's assume DDL to be same for both the tables involved in a join
> {code}
> CREATE TABLE LeftTable (id1 CHAR(6) NOT NULL,id2 VARCHAR(22) NOT
> NULL,id3 VARCHAR(12) NOT NULL,id4 CHAR(2) NOT NULL,id5 CHAR(6)
> NOT NULL, id6 VARCHAR(200) NOT NULL,id7 VARCHAR(50) NOT NULL,ts
> TIMESTAMP ,CONSTRAINT PK_JOIN_AND_INTERSECTION_TABLE PRIMARY
> KEY(id1,id2,id3,id4,id5,id6,id7))
> {code}
> Following query return right results
> {code}
> SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
> m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and
> m.ts = r.ts where r.id1 IN ('201904','201905') and r.id2 = 'ID2_VAL' and
> r.id3 IN ('ID3_VAL','ID3_VAL2')
> {code}
> but When to optimize the query, filters for the left table are also added ,
> query returned empty result . Though the filters are based on join condition
> so semantically above query and below query should be same.
> {code}
> SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
> m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and
> m.ts = r.ts where m.id1 IN ('201904','201905') and r.id1 IN
> ('201904','201905') and r.id2 = 'ID2_VAL' and m.id3 IN
> ('ID3_VAL','ID3_VAL2') and r.id3 IN ('ID3_VAL','ID3_VAL2')
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5884) Join query return empty result when filters for both the tables are present
[
https://issues.apache.org/jira/browse/PHOENIX-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated PHOENIX-5884:
-
Attachment: PHOENIX-5884.master.v4.patch
> Join query return empty result when filters for both the tables are present
> ---
>
> Key: PHOENIX-5884
> URL: https://issues.apache.org/jira/browse/PHOENIX-5884
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.0
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Attachments: PHOENIX-5884.master.v2.patch,
> PHOENIX-5884.master.v3.patch, PHOENIX-5884.master.v4.patch,
> PHOENIX-5884_v1.patch
>
>
> Let's assume DDL to be same for both the tables involved in a join
> {code}
> CREATE TABLE LeftTable (id1 CHAR(6) NOT NULL,id2 VARCHAR(22) NOT
> NULL,id3 VARCHAR(12) NOT NULL,id4 CHAR(2) NOT NULL,id5 CHAR(6)
> NOT NULL, id6 VARCHAR(200) NOT NULL,id7 VARCHAR(50) NOT NULL,ts
> TIMESTAMP ,CONSTRAINT PK_JOIN_AND_INTERSECTION_TABLE PRIMARY
> KEY(id1,id2,id3,id4,id5,id6,id7))
> {code}
> Following query return right results
> {code}
> SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
> m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and
> m.ts = r.ts where r.id1 IN ('201904','201905') and r.id2 = 'ID2_VAL' and
> r.id3 IN ('ID3_VAL','ID3_VAL2')
> {code}
> but When to optimize the query, filters for the left table are also added ,
> query returned empty result . Though the filters are based on join condition
> so semantically above query and below query should be same.
> {code}
> SELECT m.*,r.* FROM LEFT_TABLE m join RIGHT_TABLE r on m.id3 = r.id3 and
> m.id2 = r.id2 and m.id4 = r.id4 and m.id5 = r.id5 and m.id1 = r.id1 and
> m.ts = r.ts where m.id1 IN ('201904','201905') and r.id1 IN
> ('201904','201905') and r.id2 = 'ID2_VAL' and m.id3 IN
> ('ID3_VAL','ID3_VAL2') and r.id3 IN ('ID3_VAL','ID3_VAL2')
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5905) Reset user to hbase by changing rpc context before getting user permissions on access controller service
[ https://issues.apache.org/jira/browse/PHOENIX-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla updated PHOENIX-5905: - Attachment: PHOENIX-5905_addendum.patch > Reset user to hbase by changing rpc context before getting user permissions > on access controller service > - > > Key: PHOENIX-5905 > URL: https://issues.apache.org/jira/browse/PHOENIX-5905 > Project: Phoenix > Issue Type: Bug >Reporter: Rajeshbabu Chintaguntla >Assignee: Rajeshbabu Chintaguntla >Priority: Major > Fix For: 5.1.0, 4.16.0 > > Attachments: PHOENIX-5905.patch, PHOENIX-5905_addendum.patch > > > Currently we are calling getUserPermissions with hbase user directly on > access controller service which is not a rpc call. If we don't reset user > system user will be considered and might expect extra privileges to return > the user permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (PHOENIX-5905) Reset user to hbase by changing rpc context before getting user permissions on access controller service
[ https://issues.apache.org/jira/browse/PHOENIX-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla reopened PHOENIX-5905: -- [~stoty]you are correct missed to add the changes in get user defined permissions. Will upload addendum. Thanks > Reset user to hbase by changing rpc context before getting user permissions > on access controller service > - > > Key: PHOENIX-5905 > URL: https://issues.apache.org/jira/browse/PHOENIX-5905 > Project: Phoenix > Issue Type: Bug >Reporter: Rajeshbabu Chintaguntla >Assignee: Rajeshbabu Chintaguntla >Priority: Major > Fix For: 5.1.0, 4.16.0 > > Attachments: PHOENIX-5905.patch > > > Currently we are calling getUserPermissions with hbase user directly on > access controller service which is not a rpc call. If we don't reset user > system user will be considered and might expect extra privileges to return > the user permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
