[jira] [Created] (PHOENIX-6205) use count with 'case when' is not correct
Future.Zhang created PHOENIX-6205:
-
Summary: use count with 'case when' is not correct
Key: PHOENIX-6205
URL: https://issues.apache.org/jira/browse/PHOENIX-6205
Project: Phoenix
Issue Type: Bug
Components: core
Affects Versions: 5.0.0
Environment: OS: CentOS 7.3
HBase: 2.0.0
Reporter: Future.Zhang
Attachments: image-2020-10-23-14-24-35-085.png,
image-2020-10-23-14-26-58-256.png
*Query1 and result:*
{code:java}
SELECT REPAIR_NODE_CODE, THEME_ID , DATABASE_ID, OBJECT_NAME,
count(1) AS aaa,
count(CASE WHEN EXPORT_SQL_BATCH_NO is NULL THEN 1 ELSE null end) AS
notexport,
count(CASE WHEN EXPORT_SQL_BATCH_NO IS NOT NULL THEN 1 ELSE null END) AS export
FROM QM_CK_RESULT.QM_CK_RESULT
WHERE REPAIR_NODE_CODE IS NOT NULL
AND STATUS='7'
AND REPAIR_TYPE IN ('1','2')
GROUP BY REPAIR_NODE_CODE, THEME_ID , DATABASE_ID, OBJECT_NAME
{code}
the EXPORT column result is：
!image-2020-10-23-14-24-35-085.png|width=671,height=103!
*Query2 and result:*
{code:java}
SELECT REPAIR_NODE_CODE, THEME_ID , DATABASE_ID, OBJECT_NAME,
count(1) AS aaa,
count(CASE WHEN EXPORT_SQL_BATCH_NO is NULL THEN 1 ELSE null end) AS
notexport,
count(CASE WHEN EXPORT_SQL_BATCH_NO IS NOT NULL THEN 2 ELSE null END) AS export
FROM QM_CK_RESULT.QM_CK_RESULT
WHERE REPAIR_NODE_CODE IS NOT NULL
AND STATUS='7'
AND REPAIR_TYPE IN ('1','2')
GROUP BY REPAIR_NODE_CODE, THEME_ID , DATABASE_ID, OBJECT_NAME
{code}
the EXPORT column result is：
*!image-2020-10-23-14-26-58-256.png|width=642,height=94!*
*The* distinction between query1 and query2 is
I change query1 aggregation‘s column ‘export’ conditon
{code:java}
count(CASE WHEN EXPORT_SQL_BATCH_NO IS NOT NULL THEN 2 ELSE null END) AS export
{code}
‘1’ to ‘2’ .
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (PHOENIX-6204) Provide a way to preserve HBase cell timestamps when running UPSERT SELECT statements
Chinmay Kulkarni created PHOENIX-6204: - Summary: Provide a way to preserve HBase cell timestamps when running UPSERT SELECT statements Key: PHOENIX-6204 URL: https://issues.apache.org/jira/browse/PHOENIX-6204 Project: Phoenix Issue Type: New Feature Affects Versions: 4.15.0 Reporter: Chinmay Kulkarni Today when we run an UPSERT SELECT statement, the data is upserted with the current wall clock time rather than using the timestamp of the cells being read via the SELECT statement. In some cases this is favorable, but in others it is not. Providing a way to do an UPSERT SELECT in which upserts use the HBase timestamp of the cells being read is a useful feature. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5998) Paged server side ungrouped aggregate operations
[ https://issues.apache.org/jira/browse/PHOENIX-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-5998: --- Attachment: PHOENIX-5998.4.x.002.patch > Paged server side ungrouped aggregate operations > - > > Key: PHOENIX-5998 > URL: https://issues.apache.org/jira/browse/PHOENIX-5998 > Project: Phoenix > Issue Type: Improvement >Reporter: Kadir OZDEMIR >Assignee: Kadir OZDEMIR >Priority: Major > Fix For: 4.x > > Attachments: PHOENIX-5998.4.x.001.patch, PHOENIX-5998.4.x.002.patch > > > Phoenix provides the option of performing upsert select and delete query > operations on the client or server side. This is decided by the Phoenix > optimizer based on configuration parameters. For the server side option, the > table operation (upsert select/delete query) is parallelized such that > multiple table regions are scanned and the mutations derived from these scans > can also be executed in parallel on the server side. However, currently there > is no paging capability and the server side operation can take long enough > lead to HBase client timeouts. When this happens, Phoenix can return failure > to its applications and the rest of the parallel scans and mutations on the > server side can still continue since Phoenix has no mechanism in place to > stop these operations before returning failure to applications. This can > create unexpected race conditions between these left-over operations and the > new operations issued by applications. Putting a limit on the number of rows > to be processed within a single RPC call (i.e., the next operation on the > scanner) on the server side using a Phoenix level paging is highly desirable > and a required step to prevent the possible race conditions. This paging > mechanism has been already implemented for index rebuild and verification > operations and proven to be effective to prevent timeouts. This paging can be > implemented for all server side operations including aggregates, upsert > selects, delete queries and so on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5998) Paged server side ungrouped aggregate operations
[ https://issues.apache.org/jira/browse/PHOENIX-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-5998: --- Summary: Paged server side ungrouped aggregate operations (was: Paged server side operations ) > Paged server side ungrouped aggregate operations > - > > Key: PHOENIX-5998 > URL: https://issues.apache.org/jira/browse/PHOENIX-5998 > Project: Phoenix > Issue Type: Improvement >Reporter: Kadir OZDEMIR >Assignee: Kadir OZDEMIR >Priority: Major > Fix For: 4.x > > > Phoenix provides the option of performing upsert select and delete query > operations on the client or server side. This is decided by the Phoenix > optimizer based on configuration parameters. For the server side option, the > table operation (upsert select/delete query) is parallelized such that > multiple table regions are scanned and the mutations derived from these scans > can also be executed in parallel on the server side. However, currently there > is no paging capability and the server side operation can take long enough > lead to HBase client timeouts. When this happens, Phoenix can return failure > to its applications and the rest of the parallel scans and mutations on the > server side can still continue since Phoenix has no mechanism in place to > stop these operations before returning failure to applications. This can > create unexpected race conditions between these left-over operations and the > new operations issued by applications. Putting a limit on the number of rows > to be processed within a single RPC call (i.e., the next operation on the > scanner) on the server side using a Phoenix level paging is highly desirable > and a required step to prevent the possible race conditions. This paging > mechanism has been already implemented for index rebuild and verification > operations and proven to be effective to prevent timeouts. This paging can be > implemented for all server side operations including aggregates, upsert > selects, delete queries and so on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6186) Store table metadata last modified timestamp in PTable / System.Catalog
[ https://issues.apache.org/jira/browse/PHOENIX-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey Jacoby updated PHOENIX-6186: - Attachment: PHOENIX-6186-4.x.patch > Store table metadata last modified timestamp in PTable / System.Catalog > --- > > Key: PHOENIX-6186 > URL: https://issues.apache.org/jira/browse/PHOENIX-6186 > Project: Phoenix > Issue Type: New Feature >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby >Priority: Major > Fix For: 4.16.0 > > Attachments: PHOENIX-6186-4.x.patch > > > There are many reasons why it's useful to know when a particular table's > metadata was last modified. It's helpful when solving cache coherency > problems, and also in order to interact with external schema registries which > may have multiple versions of a particular schema and require a timestamp to > resolve ambiguities. > This JIRA will add a last modified timestamp field to System.Catalog, to be > updated both when creating a table/view and also when adding or removing a > column. Changing purely internal Phoenix properties will not update the > timestamp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-6197) AggregateIT and StoreNullsIT hangs
[ https://issues.apache.org/jira/browse/PHOENIX-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Antal reassigned PHOENIX-6197: -- Assignee: Richard Antal > AggregateIT and StoreNullsIT hangs > -- > > Key: PHOENIX-6197 > URL: https://issues.apache.org/jira/browse/PHOENIX-6197 > Project: Phoenix > Issue Type: Bug > Components: core >Affects Versions: 5.1.0, 4.16.0 >Reporter: Istvan Toth >Assignee: Richard Antal >Priority: Blocker > > Recent 4.x builds don't finish. > The maven output shows that AggregateIT and StoreNullsIT are started, but > never complete. > All 4.x CI builds seem to be affected. > I can see the same hang on some master builds (on HBase 2.3, though that may > be a coincidence) -- This message was sent by Atlassian Jira (v8.3.4#803005)
