[jira] [Updated] (PHOENIX-1312) Do not always project the empty column family
[
https://issues.apache.org/jira/browse/PHOENIX-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ramkrishna.s.vasudevan updated PHOENIX-1312:
Attachment: Phoenix-1312.patch
Tentative patch. Not sure on other conditions to be checked. Just parking here.
> Do not always project the empty column family
> -
>
> Key: PHOENIX-1312
> URL: https://issues.apache.org/jira/browse/PHOENIX-1312
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: ramkrishna.s.vasudevan
> Attachments: Phoenix-1312.patch
>
>
> Often times, we don't need to, but it seems we always are. See
> MultiCfQueryExecIT.testGuidePostsForMultiCFs() where we run a query like this:
> {code}
> SELECT count(*) FROM multi_cf WHERE e.cpu_utilization IS NOT NULL
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-1516) Add RAND() built-in function
[ https://issues.apache.org/jira/browse/PHOENIX-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-1516: -- Attachment: 1516-v8.patch For completeness, the complete patch with the addendums. > Add RAND() built-in function > > > Key: PHOENIX-1516 > URL: https://issues.apache.org/jira/browse/PHOENIX-1516 > Project: Phoenix > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 5.0.0, 4.3 > > Attachments: 1516-v2.txt, 1516-v3.txt, 1516-v4-wip.txt, > 1516-v5-wip.txt, 1516-v6.patch, 1516-v6.patch, 1516-v7-addendum.patch, > 1516-v7-addendum2.patch, 1516-v7-addendum3.patch, 1516-v7-addendum4.patch, > 1516-v7.txt, 1516-v8.patch, 1516.txt > > > I often find it useful to generate some rows with random data. > Here's a simple RANDOM() function that we could use for that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1590) Add an Asynchronous/Deferred Delete Option
[
https://issues.apache.org/jira/browse/PHOENIX-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290794#comment-14290794
]
James Taylor commented on PHOENIX-1590:
---
Thinking about this a bit more, I think I like your original idea better,
[~jfernando_sfdc]: supporting a deferred delete of the data on a DROP VIEW
command (if the view is updatable). Supporting it in-general on DELETE becomes
very eventually-consistent-like and is very non standard. Though still non
standard on the DROP statement, it's less important as there are frequently
vendor-specific options on DDL commands.
Not sure of the best syntax, maybe one of these?
{code}
DROP VIEW foo DEFERRED DELETE
DROP VIEW foo DELETE ALL
DROP VIEW foo INCLUDE DATA
{code}
Not sure how best to handle corner cases, in particular, what happens if you
create another VIEW with the same or overlapping WHERE clause before the data
has actually been deleted? If the VIEW is tenant specific and we, by convention
name the VIEW the same as the TABLE, then attempts to CREATE a new VIEW would
fail until the data is actually deleted. That might be ok for our usage, but
there's a lot of ifs there. :-)
Also, implementation-wise, not sure best how to track this. Maybe one way would
be to mark the status of the view and it's indexes with a new value of
DEFERRED_DELETE. Then, at compaction-time, we'd query the SYSTEM.CATALOG table
to see if the table being compacted has views in a DEFERRED_DELETE state,
collect up the view WHERE clauses, and generate a filter that could be used to
evaluate if the row is included. We'd taking advantage of HBASE-12859 to know
when we could remove the VIEW from the SYSTEM.CATALOG.
Thoughts, [~lhofhansl], [~jfernando_sfdc]?
> Add an Asynchronous/Deferred Delete Option
> --
>
> Key: PHOENIX-1590
> URL: https://issues.apache.org/jira/browse/PHOENIX-1590
> Project: Phoenix
> Issue Type: New Feature
>Reporter: Jan Fernando
>
> For use cases where we need to delete very large amounts of data from Phoenix
> tables running a synchronous delete can be problematic. In order to guarantee
> that the delete completes, handle failure scenarios, and ensure it doesn't
> put too much load on the HBase cluster and crowd out other queries running we
> need to build tooling around the longer running delete operations to chunk
> them up, provide retries in the event of failures, and have ways to throttle
> delete load if the Region Servers get hot.
> It would be really great if Phoenix offered a way to invoke a resilient
> delete that was processed asynchronously and had minimal load on the cluster.
> An idea mentioned to implement this is to introduce a DEFERRED keyword to the
> DELETE operation and for such a delete to remove the data at compaction time.
> For our use cases, ideally, we would like to set delete filters that are
> based on the first 2 elements of the row key (a multi-tenant id and the next
> item).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1590) Add an Asynchronous/Deferred Delete Option
[ https://issues.apache.org/jira/browse/PHOENIX-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290899#comment-14290899 ] Lars Hofhansl commented on PHOENIX-1590: Sounds good to me. I'll commit HBASE-12859 soon. > Add an Asynchronous/Deferred Delete Option > -- > > Key: PHOENIX-1590 > URL: https://issues.apache.org/jira/browse/PHOENIX-1590 > Project: Phoenix > Issue Type: New Feature >Reporter: Jan Fernando > > For use cases where we need to delete very large amounts of data from Phoenix > tables running a synchronous delete can be problematic. In order to guarantee > that the delete completes, handle failure scenarios, and ensure it doesn't > put too much load on the HBase cluster and crowd out other queries running we > need to build tooling around the longer running delete operations to chunk > them up, provide retries in the event of failures, and have ways to throttle > delete load if the Region Servers get hot. > It would be really great if Phoenix offered a way to invoke a resilient > delete that was processed asynchronously and had minimal load on the cluster. > An idea mentioned to implement this is to introduce a DEFERRED keyword to the > DELETE operation and for such a delete to remove the data at compaction time. > For our use cases, ideally, we would like to set delete filters that are > based on the first 2 elements of the row key (a multi-tenant id and the next > item). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1590) Add an Asynchronous/Deferred Delete Option
[ https://issues.apache.org/jira/browse/PHOENIX-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290907#comment-14290907 ] Lars Hofhansl commented on PHOENIX-1590: See my comment on HBASE-12859 for implementation options. > Add an Asynchronous/Deferred Delete Option > -- > > Key: PHOENIX-1590 > URL: https://issues.apache.org/jira/browse/PHOENIX-1590 > Project: Phoenix > Issue Type: New Feature >Reporter: Jan Fernando > > For use cases where we need to delete very large amounts of data from Phoenix > tables running a synchronous delete can be problematic. In order to guarantee > that the delete completes, handle failure scenarios, and ensure it doesn't > put too much load on the HBase cluster and crowd out other queries running we > need to build tooling around the longer running delete operations to chunk > them up, provide retries in the event of failures, and have ways to throttle > delete load if the Region Servers get hot. > It would be really great if Phoenix offered a way to invoke a resilient > delete that was processed asynchronously and had minimal load on the cluster. > An idea mentioned to implement this is to introduce a DEFERRED keyword to the > DELETE operation and for such a delete to remove the data at compaction time. > For our use cases, ideally, we would like to set delete filters that are > based on the first 2 elements of the row key (a multi-tenant id and the next > item). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1590) Add an Asynchronous/Deferred Delete Option
[ https://issues.apache.org/jira/browse/PHOENIX-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290920#comment-14290920 ] James Taylor commented on PHOENIX-1590: --- Another option for determining when it's ok to remove the VIEW metadata row would be to do it if/when another view with the same name is attempted to be created. That way we could do it from the client. I think the downside may be that each region on a major compaction would still think it needs to filter out the deferred deleted data. Or maybe the per region compaction time would help here? > Add an Asynchronous/Deferred Delete Option > -- > > Key: PHOENIX-1590 > URL: https://issues.apache.org/jira/browse/PHOENIX-1590 > Project: Phoenix > Issue Type: New Feature >Reporter: Jan Fernando > > For use cases where we need to delete very large amounts of data from Phoenix > tables running a synchronous delete can be problematic. In order to guarantee > that the delete completes, handle failure scenarios, and ensure it doesn't > put too much load on the HBase cluster and crowd out other queries running we > need to build tooling around the longer running delete operations to chunk > them up, provide retries in the event of failures, and have ways to throttle > delete load if the Region Servers get hot. > It would be really great if Phoenix offered a way to invoke a resilient > delete that was processed asynchronously and had minimal load on the cluster. > An idea mentioned to implement this is to introduce a DEFERRED keyword to the > DELETE operation and for such a delete to remove the data at compaction time. > For our use cases, ideally, we would like to set delete filters that are > based on the first 2 elements of the row key (a multi-tenant id and the next > item). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-1605) Update pom to latest stable sqlline release
James Taylor created PHOENIX-1605: - Summary: Update pom to latest stable sqlline release Key: PHOENIX-1605 URL: https://issues.apache.org/jira/browse/PHOENIX-1605 Project: Phoenix Issue Type: Bug Reporter: James Taylor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-1606) Update JDBC version to 4.3
James Taylor created PHOENIX-1606: - Summary: Update JDBC version to 4.3 Key: PHOENIX-1606 URL: https://issues.apache.org/jira/browse/PHOENIX-1606 Project: Phoenix Issue Type: Bug Reporter: James Taylor Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1605) Update pom to latest stable sqlline release
[ https://issues.apache.org/jira/browse/PHOENIX-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-1605: -- Priority: Trivial (was: Major) > Update pom to latest stable sqlline release > --- > > Key: PHOENIX-1605 > URL: https://issues.apache.org/jira/browse/PHOENIX-1605 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1605) Update pom to latest stable sqlline release
[ https://issues.apache.org/jira/browse/PHOENIX-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-1605: -- Attachment: PHOENIX-1605.patch > Update pom to latest stable sqlline release > --- > > Key: PHOENIX-1605 > URL: https://issues.apache.org/jira/browse/PHOENIX-1605 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Trivial > Attachments: PHOENIX-1605.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1606) Update JDBC version to 4.3
[ https://issues.apache.org/jira/browse/PHOENIX-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-1606: -- Attachment: PHOENIX-1606.patch > Update JDBC version to 4.3 > -- > > Key: PHOENIX-1606 > URL: https://issues.apache.org/jira/browse/PHOENIX-1606 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Trivial > Attachments: PHOENIX-1606.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1606) Update JDBC version to match release version
[ https://issues.apache.org/jira/browse/PHOENIX-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-1606: -- Summary: Update JDBC version to match release version (was: Update JDBC version to 4.3) > Update JDBC version to match release version > > > Key: PHOENIX-1606 > URL: https://issues.apache.org/jira/browse/PHOENIX-1606 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Trivial > Attachments: PHOENIX-1606.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PHOENIX-1606) Update JDBC version to match release version
[ https://issues.apache.org/jira/browse/PHOENIX-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor resolved PHOENIX-1606. --- Resolution: Fixed Fix Version/s: 3.3 4.3 Assignee: James Taylor > Update JDBC version to match release version > > > Key: PHOENIX-1606 > URL: https://issues.apache.org/jira/browse/PHOENIX-1606 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor >Priority: Trivial > Fix For: 4.3, 3.3 > > Attachments: PHOENIX-1606.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1605) Update pom to latest stable sqlline release
[ https://issues.apache.org/jira/browse/PHOENIX-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-1605: -- Affects Version/s: 3.3 4.3 Assignee: James Taylor > Update pom to latest stable sqlline release > --- > > Key: PHOENIX-1605 > URL: https://issues.apache.org/jira/browse/PHOENIX-1605 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3, 3.3 >Reporter: James Taylor >Assignee: James Taylor >Priority: Trivial > Attachments: PHOENIX-1605.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1605) Update pom to latest stable sqlline release
[ https://issues.apache.org/jira/browse/PHOENIX-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290958#comment-14290958 ] Hudson commented on PHOENIX-1605: - SUCCESS: Integrated in Phoenix-master #572 (See [https://builds.apache.org/job/Phoenix-master/572/]) PHOENIX-1605 Update pom to latest stable sqlline release (jtaylor: rev b12ddfa3f2d7c8c60b17c3f56edc7605264b0e4b) * pom.xml > Update pom to latest stable sqlline release > --- > > Key: PHOENIX-1605 > URL: https://issues.apache.org/jira/browse/PHOENIX-1605 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3, 3.3 >Reporter: James Taylor >Assignee: James Taylor >Priority: Trivial > Attachments: PHOENIX-1605.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1606) Update JDBC version to match release version
[ https://issues.apache.org/jira/browse/PHOENIX-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290959#comment-14290959 ] Hudson commented on PHOENIX-1606: - SUCCESS: Integrated in Phoenix-3.0-hadoop1 #358 (See [https://builds.apache.org/job/Phoenix-3.0-hadoop1/358/]) PHOENIX-1606 Update JDBC version to match release version (jtaylor: rev bf81936a39a06f6fc40b586786247b87b1afae43) * phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataProtocol.java > Update JDBC version to match release version > > > Key: PHOENIX-1606 > URL: https://issues.apache.org/jira/browse/PHOENIX-1606 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor >Priority: Trivial > Fix For: 4.3, 3.3 > > Attachments: PHOENIX-1606.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
