[jira] [Commented] (PHOENIX-2715) Query Log
[ https://issues.apache.org/jira/browse/PHOENIX-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445335#comment-16445335 ] Ankit Singhal commented on PHOENIX-2715: Thanks [~apurtell] for notifying the failure. I have pushed the test fix now. > Query Log > - > > Key: PHOENIX-2715 > URL: https://issues.apache.org/jira/browse/PHOENIX-2715 > Project: Phoenix > Issue Type: New Feature >Reporter: Nick Dimiduk >Assignee: Ankit Singhal >Priority: Major > Fix For: 4.14.0, 5.0.0 > > Attachments: PHOENIX-2715.patch, PHOENIX-2715_master.patch, > PHOENIX-2715_master_V1.patch, PHOENIX-2715_master_V2.patch > > > One useful feature of other database systems is the query log. It allows the > DBA to review the queries run, who's run them, time taken, This serves > both as an audit and also as a source of "ground truth" for performance > optimization. For instance, which columns should be indexed. It may also > serve as the foundation for automated performance recommendations/actions. > What queries are being run is the first piece. Have this data tied into > tracing results and perhaps client-side metrics (PHOENIX-1819) becomes very > useful. > This might take the form of clients writing data to a new system table, but > other implementation suggestions are welcome. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4698) Tolerate orphaned views
[ https://issues.apache.org/jira/browse/PHOENIX-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445246#comment-16445246 ] Maddineni Sukumar commented on PHOENIX-4698: Thanks James, for creating Jira and pushing the patch. > Tolerate orphaned views > --- > > Key: PHOENIX-4698 > URL: https://issues.apache.org/jira/browse/PHOENIX-4698 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Maddineni Sukumar >Priority: Major > Fix For: 4.14.0, 5.0.0 > > Attachments: PHOENIX-4698.patch > > > It's possible that under rare circumstances that views get orphaned. We > should make sure that this situation is tolerated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4601) Perform server-side retries if client version < 4.14
[ https://issues.apache.org/jira/browse/PHOENIX-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445050#comment-16445050 ] James Taylor commented on PHOENIX-4601: --- +1. Thanks, [~vincentpoon]! > Perform server-side retries if client version < 4.14 > > > Key: PHOENIX-4601 > URL: https://issues.apache.org/jira/browse/PHOENIX-4601 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Major > Attachments: PHOENIX-4601.v1.master.patch > > > The client version is now available on the server side when index maintenance > is being performed. Given that this information is available, we should > conditionally retry on the server depending on the client version (instead of > relying on the operator to manually update the config after clients have been > upgraded). > With PHOENIX-4613, the client version has been threaded through to the > IndexCommitter.write() method. All that's left to do is: > - Always set the config on the server side to have no HBase retries. > - Add catch of IOException and conditionally call the retrying exception > handler code based on clientVersion < 4.14.0 in > TrackingParallelWriterIndexCommitter and ParallelWriterIndexCommitter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4666) Add a subquery cache that persists beyond the life of a query
[
https://issues.apache.org/jira/browse/PHOENIX-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445048#comment-16445048
]
Maryann Xue commented on PHOENIX-4666:
--
Thank you for the PR, [~ortutay]! Looking at it now.
> Add a subquery cache that persists beyond the life of a query
> -
>
> Key: PHOENIX-4666
> URL: https://issues.apache.org/jira/browse/PHOENIX-4666
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Marcell Ortutay
>Assignee: Marcell Ortutay
>Priority: Major
>
> The user list thread for additional context is here:
> [https://lists.apache.org/thread.html/e62a6f5d79bdf7cd238ea79aed8886816d21224d12b0f1fe9b6bb075@%3Cuser.phoenix.apache.org%3E]
>
> A Phoenix query may contain expensive subqueries, and moreover those
> expensive subqueries may be used across multiple different queries. While
> whole result caching is possible at the application level, it is not possible
> to cache subresults in the application. This can cause bad performance for
> queries in which the subquery is the most expensive part of the query, and
> the application is powerless to do anything at the query level. It would be
> good if Phoenix provided a way to cache subquery results, as it would provide
> a significant performance gain.
> An illustrative example:
> SELECT * FROM table1 JOIN (SELECT id_1 FROM large_table WHERE x = 10)
> expensive_result ON table1.id_1 = expensive_result.id_2 AND table1.id_1 =
> \{id}
> In this case, the subquery "expensive_result" is expensive to compute, but it
> doesn't change between queries. The rest of the query does because of the
> \{id} parameter. This means the application can't cache it, but it would be
> good if there was a way to cache expensive_result.
> Note that there is currently a coprocessor based "server cache", but the data
> in this "cache" is not persisted across queries. It is deleted after a TTL
> expires (30sec by default), or when the query completes.
> This is issue is fairly high priority for us at 23andMe and we'd be happy to
> provide a patch with some guidance from Phoenix maintainers. We are currently
> putting together a design document for a solution, and we'll post it to this
> Jira ticket for review in a few days.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4601) Perform server-side retries if client version < 4.14
[ https://issues.apache.org/jira/browse/PHOENIX-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-4601: -- Attachment: PHOENIX-4601.v1.master.patch > Perform server-side retries if client version < 4.14 > > > Key: PHOENIX-4601 > URL: https://issues.apache.org/jira/browse/PHOENIX-4601 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Major > Attachments: PHOENIX-4601.v1.master.patch > > > The client version is now available on the server side when index maintenance > is being performed. Given that this information is available, we should > conditionally retry on the server depending on the client version (instead of > relying on the operator to manually update the config after clients have been > upgraded). > With PHOENIX-4613, the client version has been threaded through to the > IndexCommitter.write() method. All that's left to do is: > - Always set the config on the server side to have no HBase retries. > - Add catch of IOException and conditionally call the retrying exception > handler code based on clientVersion < 4.14.0 in > TrackingParallelWriterIndexCommitter and ParallelWriterIndexCommitter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4600) Add retry logic for partial index rebuilder writes
[ https://issues.apache.org/jira/browse/PHOENIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444918#comment-16444918 ] Hudson commented on PHOENIX-4600: - SUCCESS: Integrated in Jenkins build Phoenix-4.x-HBase-1.3 #100 (See [https://builds.apache.org/job/Phoenix-4.x-HBase-1.3/100/]) PHOENIX-4600 Add retry logic for partial index rebuilder writes (vincentpoon: rev 9a0e553b505b265dea517479a0f36dee6f0de76a) * (edit) phoenix-core/src/main/java/org/apache/phoenix/coprocessor/UngroupedAggregateRegionObserver.java * (add) phoenix-core/src/it/java/org/apache/phoenix/end2end/index/MutableIndexRebuilderIT.java > Add retry logic for partial index rebuilder writes > -- > > Key: PHOENIX-4600 > URL: https://issues.apache.org/jira/browse/PHOENIX-4600 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Blocker > Fix For: 4.14.0 > > Attachments: PHOENIX-4600.v1.0.98.patch, PHOENIX-4600.v1.master.patch > > > A little bit of follow up work is necessary as part of PHOENIX-4130. It looks > like the partial index rebuilder writes > (UngroupedAggregateRegionObserver.rebuildIndices()) do not have the new retry > logic that's necessary. It's somewhat unfortunate that the logic isn't shared > between the commits that happen in the loop of > UngroupedAggregateRegionObserver.doPostScannerOpen() and rebuildIndices() as > it'd be almost identical (except we know that all writes will be local > writes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4699) Stop scan after finding first child of table during drop
[ https://issues.apache.org/jira/browse/PHOENIX-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444892#comment-16444892 ] Mujtaba Chohan commented on PHOENIX-4699: - +1 > Stop scan after finding first child of table during drop > > > Key: PHOENIX-4699 > URL: https://issues.apache.org/jira/browse/PHOENIX-4699 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > Fix For: 4.14.0, 5.0.0 > > Attachments: PHOENIX-4699.patch > > > Rather than scan all children when dropping a table or view, we should stop > at the first one (unless we've issued a drop cascade). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4698) Tolerate orphaned views
[ https://issues.apache.org/jira/browse/PHOENIX-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4698: -- Fix Version/s: 5.0.0 4.14.0 > Tolerate orphaned views > --- > > Key: PHOENIX-4698 > URL: https://issues.apache.org/jira/browse/PHOENIX-4698 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Maddineni Sukumar >Priority: Major > Fix For: 4.14.0, 5.0.0 > > Attachments: PHOENIX-4698.patch > > > It's possible that under rare circumstances that views get orphaned. We > should make sure that this situation is tolerated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4699) Stop scan after finding first child of table during drop
[ https://issues.apache.org/jira/browse/PHOENIX-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4699: -- Fix Version/s: 5.0.0 4.14.0 > Stop scan after finding first child of table during drop > > > Key: PHOENIX-4699 > URL: https://issues.apache.org/jira/browse/PHOENIX-4699 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > Fix For: 4.14.0, 5.0.0 > > Attachments: PHOENIX-4699.patch > > > Rather than scan all children when dropping a table or view, we should stop > at the first one (unless we've issued a drop cascade). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4694) Prevent locking of parent table when dropping view to reduce contention
[ https://issues.apache.org/jira/browse/PHOENIX-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4694: -- Attachment: PHOENIX-4694.patch > Prevent locking of parent table when dropping view to reduce contention > --- > > Key: PHOENIX-4694 > URL: https://issues.apache.org/jira/browse/PHOENIX-4694 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > Fix For: 4.14.0, 5.0.0 > > Attachments: PHOENIX-4694.patch > > > When there are many views with the same parent table, there's a lot of > contention when adding new views and dropping existing views. The lock is > only necessary when creating/dropping indexes, so should be removed in the > case of views. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (PHOENIX-4694) Prevent locking of parent table when dropping view to reduce contention
[ https://issues.apache.org/jira/browse/PHOENIX-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444883#comment-16444883 ] James Taylor edited comment on PHOENIX-4694 at 4/19/18 10:10 PM: - The lock on the parent during creation of a view is need to prevent a race condition between creating a view and adding/dropping a column from a base table. This will no longer be required after PHOENIX-3534. For now, we can reduce contention by not locking the parent during drop as that's not required. Please review, [~vincentpoon]. was (Author: jamestaylor): The lock on the parent during creation of a view is need to prevent a race condition between creating a view and adding/dropping a column from a base table. This will no longer be required after PHOENIX-3534. For now, we can reduce contention by not locking the parent during drop as that's not required. > Prevent locking of parent table when dropping view to reduce contention > --- > > Key: PHOENIX-4694 > URL: https://issues.apache.org/jira/browse/PHOENIX-4694 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > Fix For: 4.14.0, 5.0.0 > > Attachments: PHOENIX-4694.patch > > > When there are many views with the same parent table, there's a lot of > contention when adding new views and dropping existing views. The lock is > only necessary when creating/dropping indexes, so should be removed in the > case of views. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4694) Prevent locking of parent table when dropping view to reduce contention
[ https://issues.apache.org/jira/browse/PHOENIX-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444883#comment-16444883 ] James Taylor commented on PHOENIX-4694: --- The lock on the parent during creation of a view is need to prevent a race condition between creating a view and adding/dropping a column from a base table. This will no longer be required after PHOENIX-3534. For now, we can reduce contention by not locking the parent during drop as that's not required. > Prevent locking of parent table when dropping view to reduce contention > --- > > Key: PHOENIX-4694 > URL: https://issues.apache.org/jira/browse/PHOENIX-4694 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > Fix For: 4.14.0, 5.0.0 > > > When there are many views with the same parent table, there's a lot of > contention when adding new views and dropping existing views. The lock is > only necessary when creating/dropping indexes, so should be removed in the > case of views. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4694) Prevent locking of parent table when dropping view to reduce contention
[ https://issues.apache.org/jira/browse/PHOENIX-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4694: -- Summary: Prevent locking of parent table when dropping view to reduce contention (was: Prevent locking of parent table during view creation and drop) > Prevent locking of parent table when dropping view to reduce contention > --- > > Key: PHOENIX-4694 > URL: https://issues.apache.org/jira/browse/PHOENIX-4694 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > Fix For: 4.14.0, 5.0.0 > > > When there are many views with the same parent table, there's a lot of > contention when adding new views and dropping existing views. The lock is > only necessary when creating/dropping indexes, so should be removed in the > case of views. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4694) Prevent locking of parent table during view creation and drop
[ https://issues.apache.org/jira/browse/PHOENIX-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4694: -- Fix Version/s: 5.0.0 4.14.0 > Prevent locking of parent table during view creation and drop > - > > Key: PHOENIX-4694 > URL: https://issues.apache.org/jira/browse/PHOENIX-4694 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > Fix For: 4.14.0, 5.0.0 > > > When there are many views with the same parent table, there's a lot of > contention when adding new views and dropping existing views. The lock is > only necessary when creating/dropping indexes, so should be removed in the > case of views. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4613) Thread clientVersion through to IndexCommitter implementors
[ https://issues.apache.org/jira/browse/PHOENIX-4613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444875#comment-16444875 ] James Taylor commented on PHOENIX-4613: --- Thanks, [~vincentpoon]. +1 > Thread clientVersion through to IndexCommitter implementors > --- > > Key: PHOENIX-4613 > URL: https://issues.apache.org/jira/browse/PHOENIX-4613 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4613_v1.patch, PHOENIX-4613_v1.rebase.mater.patch > > > In support of PHOENIX-4601, thread the client version into the implementors > of IndexCommitter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4613) Thread clientVersion through to IndexCommitter implementors
[ https://issues.apache.org/jira/browse/PHOENIX-4613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-4613: -- Attachment: PHOENIX-4613_v1.rebase.mater.patch > Thread clientVersion through to IndexCommitter implementors > --- > > Key: PHOENIX-4613 > URL: https://issues.apache.org/jira/browse/PHOENIX-4613 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor >Priority: Major > Fix For: 4.14.0 > > Attachments: PHOENIX-4613_v1.patch, PHOENIX-4613_v1.rebase.mater.patch > > > In support of PHOENIX-4601, thread the client version into the implementors > of IndexCommitter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4600) Add retry logic for partial index rebuilder writes
[ https://issues.apache.org/jira/browse/PHOENIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444845#comment-16444845 ] Hudson commented on PHOENIX-4600: - FAILURE: Integrated in Jenkins build Phoenix-4.x-HBase-0.98 #1863 (See [https://builds.apache.org/job/Phoenix-4.x-HBase-0.98/1863/]) PHOENIX-4600 Add retry logic for partial index rebuilder writes (vincentpoon: rev 62b2a3e180c11bfe26df07bf945837cf71f1f506) * (add) phoenix-core/src/it/java/org/apache/phoenix/end2end/index/MutableIndexRebuilderIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/coprocessor/UngroupedAggregateRegionObserver.java > Add retry logic for partial index rebuilder writes > -- > > Key: PHOENIX-4600 > URL: https://issues.apache.org/jira/browse/PHOENIX-4600 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Blocker > Fix For: 4.14.0 > > Attachments: PHOENIX-4600.v1.0.98.patch, PHOENIX-4600.v1.master.patch > > > A little bit of follow up work is necessary as part of PHOENIX-4130. It looks > like the partial index rebuilder writes > (UngroupedAggregateRegionObserver.rebuildIndices()) do not have the new retry > logic that's necessary. It's somewhat unfortunate that the logic isn't shared > between the commits that happen in the loop of > UngroupedAggregateRegionObserver.doPostScannerOpen() and rebuildIndices() as > it'd be almost identical (except we know that all writes will be local > writes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4698) Tolerate orphaned views
[ https://issues.apache.org/jira/browse/PHOENIX-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444842#comment-16444842 ] James Taylor commented on PHOENIX-4698: --- +1. Thanks for the contribution, [~sukuna...@gmail.com]. > Tolerate orphaned views > --- > > Key: PHOENIX-4698 > URL: https://issues.apache.org/jira/browse/PHOENIX-4698 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Maddineni Sukumar >Priority: Major > Attachments: PHOENIX-4698.patch > > > It's possible that under rare circumstances that views get orphaned. We > should make sure that this situation is tolerated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4698) Tolerate orphaned views
[ https://issues.apache.org/jira/browse/PHOENIX-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4698: -- Attachment: PHOENIX-4698.patch > Tolerate orphaned views > --- > > Key: PHOENIX-4698 > URL: https://issues.apache.org/jira/browse/PHOENIX-4698 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Maddineni Sukumar >Priority: Major > Attachments: PHOENIX-4698.patch > > > It's possible that under rare circumstances that views get orphaned. We > should make sure that this situation is tolerated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (PHOENIX-4698) Tolerate orphaned views
[ https://issues.apache.org/jira/browse/PHOENIX-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor reassigned PHOENIX-4698: - Assignee: Maddineni Sukumar > Tolerate orphaned views > --- > > Key: PHOENIX-4698 > URL: https://issues.apache.org/jira/browse/PHOENIX-4698 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Maddineni Sukumar >Priority: Major > > It's possible that under rare circumstances that views get orphaned. We > should make sure that this situation is tolerated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4699) Stop scan after finding first child of table during drop
[ https://issues.apache.org/jira/browse/PHOENIX-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4699: -- Attachment: PHOENIX-4699.patch > Stop scan after finding first child of table during drop > > > Key: PHOENIX-4699 > URL: https://issues.apache.org/jira/browse/PHOENIX-4699 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > Attachments: PHOENIX-4699.patch > > > Rather than scan all children when dropping a table or view, we should stop > at the first one (unless we've issued a drop cascade). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4699) Stop scan after finding first child of table during drop
[ https://issues.apache.org/jira/browse/PHOENIX-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444839#comment-16444839 ] James Taylor commented on PHOENIX-4699: --- Please review, [~aertoria] or [~mujtabachohan]. > Stop scan after finding first child of table during drop > > > Key: PHOENIX-4699 > URL: https://issues.apache.org/jira/browse/PHOENIX-4699 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > Attachments: PHOENIX-4699.patch > > > Rather than scan all children when dropping a table or view, we should stop > at the first one (unless we've issued a drop cascade). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-4699) Stop scan after finding first child of table during drop
James Taylor created PHOENIX-4699: - Summary: Stop scan after finding first child of table during drop Key: PHOENIX-4699 URL: https://issues.apache.org/jira/browse/PHOENIX-4699 Project: Phoenix Issue Type: Bug Reporter: James Taylor Rather than scan all children when dropping a table or view, we should stop at the first one (unless we've issued a drop cascade). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-4698) Tolerate orphaned views
James Taylor created PHOENIX-4698: - Summary: Tolerate orphaned views Key: PHOENIX-4698 URL: https://issues.apache.org/jira/browse/PHOENIX-4698 Project: Phoenix Issue Type: Bug Reporter: James Taylor It's possible that under rare circumstances that views get orphaned. We should make sure that this situation is tolerated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4697) Don't set child links for views
[ https://issues.apache.org/jira/browse/PHOENIX-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor resolved PHOENIX-4697. --- Resolution: Won't Fix Better to wait until splittable system catalog and do the work then. > Don't set child links for views > --- > > Key: PHOENIX-4697 > URL: https://issues.apache.org/jira/browse/PHOENIX-4697 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor >Priority: Major > > Until the splittable system catalog work is complete (PHOENIX-3534), setting > child links is not a good idea. It'll bloat the size of the system catalog > and require too many row locks to ensure its accuracy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (PHOENIX-2715) Query Log
[
https://issues.apache.org/jira/browse/PHOENIX-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reopened PHOENIX-2715:
-
Looks like a minor addendum is needed, at least for 0.98, some test failures
because SYSTEM.LOG is unexpected
{noformat}
[ERROR] SystemCatalogCreationOnConnectionIT.testMigrateSysCatCreateOthers:269
expected:<[SYSTEM:FUNCTION, SYSTEM:STATS, SYSTEM:MUTEX, SYSTEM:CATALOG,
SYSTEM.LOG, SYSTEM:SEQUENCE]> but was:<[SYSTEM:FUNCTION, SYSTEM:STATS,
SYSTEM:MUTEX, SYSTEM:LOG, SYSTEM:CATALOG, SYSTEM:SEQUENCE]>
[ERROR] SystemCatalogCreationOnConnectionIT.testMigrateToSystemNamespace:199
expected:<[SYSTEM:FUNCTION, SYSTEM:STATS, SYSTEM:MUTEX, SYSTEM:CATALOG,
SYSTEM.LOG, SYSTEM:SEQUENCE]> but was:<[SYSTEM:FUNCTION, SYSTEM:STATS,
SYSTEM:MUTEX, SYSTEM:LOG, SYSTEM:CATALOG, SYSTEM:SEQUENCE]>
[ERROR]
SystemCatalogCreationOnConnectionIT.testMigrateToSystemNamespaceAndUpgradeSysCat:288
expected:<[SYSTEM:FUNCTION, SYSTEM:STATS, SYSTEM:MUTEX, SYSTEM:CATALOG,
SYSTEM.LOG, SYSTEM:SEQUENCE]> but was:<[SYSTEM:FUNCTION, SYSTEM:STATS,
SYSTEM:MUTEX, SYSTEM:LOG, SYSTEM:CATALOG, SYSTEM:SEQUENCE]>
[ERROR]
SystemCatalogCreationOnConnectionIT.testTablesExistInconsistentNSMappingFails:298->firstConnectionNSMappingServerEnabledClientEnabled:557
expected:<[SYSTEM:FUNCTION, SYSTEM:STATS, SYSTEM:MUTEX, SYSTEM:CATALOG,
SYSTEM.LOG, SYSTEM:SEQUENCE]> but was:<[SYSTEM:FUNCTION, SYSTEM:STATS,
SYSTEM:MUTEX, SYSTEM:LOG, SYSTEM:CATALOG, SYSTEM:SEQUENCE]>
[ERROR]
SystemCatalogCreationOnConnectionIT.testUpgradeAttempted:210->firstConnectionNSMappingServerEnabledClientEnabled:557
expected:<[SYSTEM:FUNCTION, SYSTEM:STATS, SYSTEM:MUTEX, SYSTEM:CATALOG,
SYSTEM.LOG, SYSTEM:SEQUENCE]> but was:<[SYSTEM:FUNCTION, SYSTEM:STATS,
SYSTEM:MUTEX, SYSTEM:LOG, SYSTEM:CATALOG, SYSTEM:SEQUENCE]>
[ERROR]
SystemCatalogCreationOnConnectionIT.testUpgradeNotAllowed:231->firstConnectionNSMappingServerEnabledClientEnabled:557
expected:<[SYSTEM:FUNCTION, SYSTEM:STATS, SYSTEM:MUTEX, SYSTEM:CATALOG,
SYSTEM.LOG, SYSTEM:SEQUENCE]> but was:<[SYSTEM:FUNCTION, SYSTEM:STATS,
SYSTEM:MUTEX, SYSTEM:LOG, SYSTEM:CATALOG, SYSTEM:SEQUENCE]>
{noformat}
> Query Log
> -
>
> Key: PHOENIX-2715
> URL: https://issues.apache.org/jira/browse/PHOENIX-2715
> Project: Phoenix
> Issue Type: New Feature
>Reporter: Nick Dimiduk
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-2715.patch, PHOENIX-2715_master.patch,
> PHOENIX-2715_master_V1.patch, PHOENIX-2715_master_V2.patch
>
>
> One useful feature of other database systems is the query log. It allows the
> DBA to review the queries run, who's run them, time taken, This serves
> both as an audit and also as a source of "ground truth" for performance
> optimization. For instance, which columns should be indexed. It may also
> serve as the foundation for automated performance recommendations/actions.
> What queries are being run is the first piece. Have this data tied into
> tracing results and perhaps client-side metrics (PHOENIX-1819) becomes very
> useful.
> This might take the form of clients writing data to a new system table, but
> other implementation suggestions are welcome.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (PHOENIX-4600) Add retry logic for partial index rebuilder writes
[ https://issues.apache.org/jira/browse/PHOENIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444726#comment-16444726 ] Vincent Poon edited comment on PHOENIX-4600 at 4/19/18 8:19 PM: pushed to master and all 4.x branches was (Author: vincentpoon): pushed to all 4.x branches > Add retry logic for partial index rebuilder writes > -- > > Key: PHOENIX-4600 > URL: https://issues.apache.org/jira/browse/PHOENIX-4600 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Blocker > Fix For: 4.14.0 > > Attachments: PHOENIX-4600.v1.0.98.patch, PHOENIX-4600.v1.master.patch > > > A little bit of follow up work is necessary as part of PHOENIX-4130. It looks > like the partial index rebuilder writes > (UngroupedAggregateRegionObserver.rebuildIndices()) do not have the new retry > logic that's necessary. It's somewhat unfortunate that the logic isn't shared > between the commits that happen in the loop of > UngroupedAggregateRegionObserver.doPostScannerOpen() and rebuildIndices() as > it'd be almost identical (except we know that all writes will be local > writes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4600) Add retry logic for partial index rebuilder writes
[ https://issues.apache.org/jira/browse/PHOENIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444726#comment-16444726 ] Vincent Poon commented on PHOENIX-4600: --- pushed to all 4.x branches > Add retry logic for partial index rebuilder writes > -- > > Key: PHOENIX-4600 > URL: https://issues.apache.org/jira/browse/PHOENIX-4600 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Blocker > Fix For: 4.14.0 > > Attachments: PHOENIX-4600.v1.0.98.patch, PHOENIX-4600.v1.master.patch > > > A little bit of follow up work is necessary as part of PHOENIX-4130. It looks > like the partial index rebuilder writes > (UngroupedAggregateRegionObserver.rebuildIndices()) do not have the new retry > logic that's necessary. It's somewhat unfortunate that the logic isn't shared > between the commits that happen in the loop of > UngroupedAggregateRegionObserver.doPostScannerOpen() and rebuildIndices() as > it'd be almost identical (except we know that all writes will be local > writes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4600) Add retry logic for partial index rebuilder writes
[ https://issues.apache.org/jira/browse/PHOENIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-4600: -- Fix Version/s: 4.14.0 > Add retry logic for partial index rebuilder writes > -- > > Key: PHOENIX-4600 > URL: https://issues.apache.org/jira/browse/PHOENIX-4600 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Blocker > Fix For: 4.14.0 > > Attachments: PHOENIX-4600.v1.0.98.patch, PHOENIX-4600.v1.master.patch > > > A little bit of follow up work is necessary as part of PHOENIX-4130. It looks > like the partial index rebuilder writes > (UngroupedAggregateRegionObserver.rebuildIndices()) do not have the new retry > logic that's necessary. It's somewhat unfortunate that the logic isn't shared > between the commits that happen in the loop of > UngroupedAggregateRegionObserver.doPostScannerOpen() and rebuildIndices() as > it'd be almost identical (except we know that all writes will be local > writes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4600) Add retry logic for partial index rebuilder writes
[ https://issues.apache.org/jira/browse/PHOENIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-4600: -- Attachment: PHOENIX-4600.v1.0.98.patch > Add retry logic for partial index rebuilder writes > -- > > Key: PHOENIX-4600 > URL: https://issues.apache.org/jira/browse/PHOENIX-4600 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Blocker > Attachments: PHOENIX-4600.v1.0.98.patch, PHOENIX-4600.v1.master.patch > > > A little bit of follow up work is necessary as part of PHOENIX-4130. It looks > like the partial index rebuilder writes > (UngroupedAggregateRegionObserver.rebuildIndices()) do not have the new retry > logic that's necessary. It's somewhat unfortunate that the logic isn't shared > between the commits that happen in the loop of > UngroupedAggregateRegionObserver.doPostScannerOpen() and rebuildIndices() as > it'd be almost identical (except we know that all writes will be local > writes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4600) Add retry logic for partial index rebuilder writes
[ https://issues.apache.org/jira/browse/PHOENIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1661#comment-1661 ] James Taylor commented on PHOENIX-4600: --- +1. Thanks, [~vincentpoon]! > Add retry logic for partial index rebuilder writes > -- > > Key: PHOENIX-4600 > URL: https://issues.apache.org/jira/browse/PHOENIX-4600 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Blocker > Attachments: PHOENIX-4600.v1.master.patch > > > A little bit of follow up work is necessary as part of PHOENIX-4130. It looks > like the partial index rebuilder writes > (UngroupedAggregateRegionObserver.rebuildIndices()) do not have the new retry > logic that's necessary. It's somewhat unfortunate that the logic isn't shared > between the commits that happen in the loop of > UngroupedAggregateRegionObserver.doPostScannerOpen() and rebuildIndices() as > it'd be almost identical (except we know that all writes will be local > writes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4600) Add retry logic for partial index rebuilder writes
[ https://issues.apache.org/jira/browse/PHOENIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1634#comment-1634 ] Vincent Poon commented on PHOENIX-4600: --- [~jamestaylor] Can you review? Thanks > Add retry logic for partial index rebuilder writes > -- > > Key: PHOENIX-4600 > URL: https://issues.apache.org/jira/browse/PHOENIX-4600 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Blocker > Attachments: PHOENIX-4600.v1.master.patch > > > A little bit of follow up work is necessary as part of PHOENIX-4130. It looks > like the partial index rebuilder writes > (UngroupedAggregateRegionObserver.rebuildIndices()) do not have the new retry > logic that's necessary. It's somewhat unfortunate that the logic isn't shared > between the commits that happen in the loop of > UngroupedAggregateRegionObserver.doPostScannerOpen() and rebuildIndices() as > it'd be almost identical (except we know that all writes will be local > writes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4600) Add retry logic for partial index rebuilder writes
[ https://issues.apache.org/jira/browse/PHOENIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-4600: -- Attachment: PHOENIX-4600.v1.master.patch > Add retry logic for partial index rebuilder writes > -- > > Key: PHOENIX-4600 > URL: https://issues.apache.org/jira/browse/PHOENIX-4600 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Blocker > Attachments: PHOENIX-4600.v1.master.patch > > > A little bit of follow up work is necessary as part of PHOENIX-4130. It looks > like the partial index rebuilder writes > (UngroupedAggregateRegionObserver.rebuildIndices()) do not have the new retry > logic that's necessary. It's somewhat unfortunate that the logic isn't shared > between the commits that happen in the loop of > UngroupedAggregateRegionObserver.doPostScannerOpen() and rebuildIndices() as > it'd be almost identical (except we know that all writes will be local > writes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (PHOENIX-4600) Add retry logic for partial index rebuilder writes
[ https://issues.apache.org/jira/browse/PHOENIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon reassigned PHOENIX-4600: - Assignee: Vincent Poon > Add retry logic for partial index rebuilder writes > -- > > Key: PHOENIX-4600 > URL: https://issues.apache.org/jira/browse/PHOENIX-4600 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Vincent Poon >Priority: Blocker > > A little bit of follow up work is necessary as part of PHOENIX-4130. It looks > like the partial index rebuilder writes > (UngroupedAggregateRegionObserver.rebuildIndices()) do not have the new retry > logic that's necessary. It's somewhat unfortunate that the logic isn't shared > between the commits that happen in the loop of > UngroupedAggregateRegionObserver.doPostScannerOpen() and rebuildIndices() as > it'd be almost identical (except we know that all writes will be local > writes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4408) Figure out Hadoop version compatibility
[ https://issues.apache.org/jira/browse/PHOENIX-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved PHOENIX-4408. - Resolution: Fixed Going towards Hadoop3 only > Figure out Hadoop version compatibility > --- > > Key: PHOENIX-4408 > URL: https://issues.apache.org/jira/browse/PHOENIX-4408 > Project: Phoenix > Issue Type: Sub-task >Reporter: Josh Elser >Priority: Blocker > Fix For: 5.0.0 > > > The 5.x-HBase-2.0 branch is presently incompatible with both Hadoop 2.7 and > Hadoop 3.0. > This stems from PhoenixMetricsSink and LoggingSink both of which extend > MetricsSink from Hadoop. Hadoop leaks a commons-configuration class into a > method signature and changes the dependency across versions. > This makes it extremely annoying to work around downstream (we would have to > create multiple maven modules to shim around this). We should figure out what > compatibility we want to have. Post PHOENIX-4405, it's only Hadoop3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-868) Make Time, Date, and Timestamp handling JDBC-compliant
[
https://issues.apache.org/jira/browse/PHOENIX-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-868:
---
Fix Version/s: (was: 5.0.0)
> Make Time, Date, and Timestamp handling JDBC-compliant
> --
>
> Key: PHOENIX-868
> URL: https://issues.apache.org/jira/browse/PHOENIX-868
> Project: Phoenix
> Issue Type: Bug
>Reporter: Gabriel Reid
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
>
> From what I understand from the JDBC documentation, the way that a
> java.sql.Date should be handled via JDBC is simply as a day, month, and year,
> despite the fact that it is internally represented as a timestamp (the same
> kind of thing applies to Time objects, which are a triple of hours, minutes,
> and seconds).
> Further, my understanding is that it is the responsibility of a JDBC driver
> to do normalization of incoming Date and Time (and maybe Timestamp) objects
> to interpret them as being in the current time zone, and remove the extra
> components (i.e. time components for a Date, and date components for a Time)
> before storing the value.
> This means that today, if I insert a column value consisting of 'new
> Date(System.currentTimeMillis())', then I should be able to retrieve that
> same value with a filter on 'Date.valueOf(“2014-03-18”)’. Additionally, that
> filter should work regardless of my own local timezone.
> It also means that if I store ‘Time.valueOf("07:00:00”)’ in a TIME field in a
> database in my current timezone, someone should get “07:00:00” if they run
> 'ResultSet#getTime(1).toString()’ on that value, even if they’re in a
> different timezone than me.
> From what I can see right now, Phoenix doesn’t currently exhibit this
> behavior. Instead, the full long representation of Date, Time, and Timestamps
> is stored directly in HBase, without dropping the extra date fields or doing
> timezone conversion.
> From the current analysis, what is required for Phoenix to be JDBC-compliant
> in terms of time/date/timestamp handling is:
> * All incoming time-style values should be interpreted in the local timezone
> of the driver, then be normalized and converted to UTC before serialization
> (unless a Calendar is supplied) in PreparedStatement calls
> * All outgoing time-style values should be converted from UTC into the local
> timezone (unless a Calendar is supplied) in ResultSet calls
> * Supplying a Calendar to PreparedStatement methods should cause the time
> value to be converted from the local timezone to the timezone of the calendar
> (instead of UTC) before being serialized
> * Supplying a Calendar to ResultSet methods should cause the time value from
> the database to be interpreted as if it was serialized in the timezone of the
> Calendar, instead of UTC.
> Making the above changes would mean breaking backwards compatibility with
> existing Phoenix installs (unless some kind of backwards-compatibility mode
> is introduced or something similar).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (PHOENIX-4470) Fix tests of type ParallelStatsDisabledTest
[ https://issues.apache.org/jira/browse/PHOENIX-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444313#comment-16444313 ] Josh Elser commented on PHOENIX-4470: - Just the Tracing test that needs love, [~an...@apache.org]? > Fix tests of type ParallelStatsDisabledTest > > > Key: PHOENIX-4470 > URL: https://issues.apache.org/jira/browse/PHOENIX-4470 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Major > Labels: HBase-2.0 > Fix For: 5.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-4697) Don't set child links for views
James Taylor created PHOENIX-4697: - Summary: Don't set child links for views Key: PHOENIX-4697 URL: https://issues.apache.org/jira/browse/PHOENIX-4697 Project: Phoenix Issue Type: Bug Reporter: James Taylor Assignee: James Taylor Until the splittable system catalog work is complete (PHOENIX-3534), setting child links is not a good idea. It'll bloat the size of the system catalog and require too many row locks to ensure its accuracy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4518) Test phoenix-kafka integration
[ https://issues.apache.org/jira/browse/PHOENIX-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved PHOENIX-4518. - Resolution: Later Fix Version/s: (was: 5.0.0) > Test phoenix-kafka integration > -- > > Key: PHOENIX-4518 > URL: https://issues.apache.org/jira/browse/PHOENIX-4518 > Project: Phoenix > Issue Type: Task >Reporter: Josh Elser >Priority: Major > > Need to test: > * Does the Kafka integration still work? > * Should the Kafka dependency version be changed? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4580) Upgrade to Tephra 0.14.0-incubating for HBase 2.0 support
[ https://issues.apache.org/jira/browse/PHOENIX-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444312#comment-16444312 ] Josh Elser commented on PHOENIX-4580: - This should be closed, [~ankit.singhal]? > Upgrade to Tephra 0.14.0-incubating for HBase 2.0 support > --- > > Key: PHOENIX-4580 > URL: https://issues.apache.org/jira/browse/PHOENIX-4580 > Project: Phoenix > Issue Type: Task >Reporter: Josh Elser >Assignee: Ankit Singhal >Priority: Blocker > Fix For: 5.0.0 > > > TEPHRA-272 has the necessary changes that Phoenix needs but we need to get a > release from the Tephra folks first. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4696) Project icon at JIRA need to change: Phoenix jira icon is not accurate
[ https://issues.apache.org/jira/browse/PHOENIX-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved PHOENIX-4696. - Resolution: Fixed Assignee: Josh Elser Done ;) > Project icon at JIRA need to change: Phoenix jira icon is not accurate > -- > > Key: PHOENIX-4696 > URL: https://issues.apache.org/jira/browse/PHOENIX-4696 > Project: Phoenix > Issue Type: Improvement >Reporter: Ethan Wang >Assignee: Josh Elser >Priority: Minor > > Just notice at the Jira page, the project icon is not accurate. purposing > changing back to Phoenix project icon. > [https://issues.apache.org/jira/projects/PHOENIX/issues/|https://issues.apache.org/jira/projects/PHOENIX/issues/PHOENIX-684?filter=allopenissues] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4665) Document python driver on website
[ https://issues.apache.org/jira/browse/PHOENIX-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved PHOENIX-4665. - Resolution: Fixed Pushed a quick landing page at https://phoenix.apache.org/python.html > Document python driver on website > - > > Key: PHOENIX-4665 > URL: https://issues.apache.org/jira/browse/PHOENIX-4665 > Project: Phoenix > Issue Type: Task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: 4.14.0, 5.0.0 > > > Prior to these releases, we should make sure that the Python driver has > documentation on the website, not just the docs in the source code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4298) refactoring to avoid using deprecated API for Put/Delete
[ https://issues.apache.org/jira/browse/PHOENIX-4298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443830#comment-16443830 ] Rajeshbabu Chintaguntla commented on PHOENIX-4298: -- Here is the patch for master branch. Going to commit it. > refactoring to avoid using deprecated API for Put/Delete > > > Key: PHOENIX-4298 > URL: https://issues.apache.org/jira/browse/PHOENIX-4298 > Project: Phoenix > Issue Type: Sub-task >Reporter: Sergey Soldatov >Assignee: Sergey Soldatov >Priority: Major > Labels: HBase-2.0 > Fix For: 4.14.0, 5.0.0 > > Attachments: PHOENIX-4298.patch, PHOENIX-4298_master.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4686) Phoenix stats does not account for server side limit push downs
[ https://issues.apache.org/jira/browse/PHOENIX-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443655#comment-16443655 ] James Taylor commented on PHOENIX-4686: --- Thanks for the wip patch, [~abhishek.chouhan]. I'd recommend following the same pattern that we have for point lookups. Just let the existing code execute as-is (we need it to calculate the scans anyway), and then at the end (if we're pushing a PageFilter, or we could detect it based on the QueryPlan as well), just multiple the row size estimate by the limit to calculate the estimated bytes scanned. Also, I think we might need a new ExplainPlan attribute like EST_BASED_ON_STATS which is set to false in this case and in the case of point lookups (since in neither case would we be relying on stats for the estimate). The reason this is useful is that in these cases, the EST_INFO_TS being null can be ignored by the client. > Phoenix stats does not account for server side limit push downs > --- > > Key: PHOENIX-4686 > URL: https://issues.apache.org/jira/browse/PHOENIX-4686 > Project: Phoenix > Issue Type: Bug >Reporter: Abhishek Singh Chouhan >Assignee: Abhishek Singh Chouhan >Priority: Major > Attachments: PHOENIX-4686-wip.master.patch > > > For a query like SELECT * FROM FOO LIMIT 10 the EST_BYTES_READ does not take > into account a limit correctly when there's no WHERE clause (or a WHERE > clause that gets compiled out into start/stop row key on the scan). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
