[jira] [Updated] (PHOENIX-5117) Return the count of rows scanned in HBase
[ https://issues.apache.org/jira/browse/PHOENIX-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chen Feng updated PHOENIX-5117: --- Attachment: PHOENIX-5117-4.x-HBase-1.4-v5.patch > Return the count of rows scanned in HBase > - > > Key: PHOENIX-5117 > URL: https://issues.apache.org/jira/browse/PHOENIX-5117 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.14.1 >Reporter: Chen Feng >Assignee: Chen Feng >Priority: Minor > Fix For: 4.15.1, 5.1.1 > > Attachments: PHOENIX-5117-4.x-HBase-1.4-v1.patch, > PHOENIX-5117-4.x-HBase-1.4-v2.patch, PHOENIX-5117-4.x-HBase-1.4-v3.patch, > PHOENIX-5117-4.x-HBase-1.4-v4.patch, PHOENIX-5117-4.x-HBase-1.4-v5.patch, > PHOENIX-5117-v1.patch > > > HBASE-5980 provides the ability to return the number of rows scanned. Such > metrics should also be returned by Phoenix. > HBASE-21815 is acquired. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5535) Index rebuilds via UngroupedAggregateRegionObserver should replay delete markers
[ https://issues.apache.org/jira/browse/PHOENIX-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-5535: --- Attachment: PHOENIX-5535.4.x-HBase-1.5.001.patch > Index rebuilds via UngroupedAggregateRegionObserver should replay delete > markers > > > Key: PHOENIX-5535 > URL: https://issues.apache.org/jira/browse/PHOENIX-5535 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.0.0, 4.14.3 >Reporter: Kadir OZDEMIR >Assignee: Kadir OZDEMIR >Priority: Blocker > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5535.4.x-HBase-1.5.001.patch, > PHOENIX-5535.master.001.patch, PHOENIX-5535.master.002.patch > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Currently index rebuilds for global index tables are done on the server side. > Phoenix client generates an aggregate plan using ServerBuildIndexCompiler to > scan every data table row on the server side . This complier sets the scan > attributes so that the row mutations that are scanned by > UngroupedRegionObserver are then replayed on the data table so that index > table rows are rebuilt. During this replay, data table row updates are > skipped and only index table row are updated. > Phoenix allows column entries to have null values. Null values are > represented by HBase column delete marker. This means that index rebuild must > replay these delete markers along with put mutations. In order to do that > ServerBuildIndexCompiler should use raw scans but currently it does use > regular scans. This leads incorrect index rebuilds when null values are used. > A simple test where a data table with one global index with a covered column > that can take null value is sufficient to reproduce this problem. > # Create a data table with columns a, b, and c where a is the primary key > and c can have null value > # Write one row with not null values > # Overwrite the covered column with null (i.e., set it to null) > # Create an index on the table where b is the secondary key and c is covered > column > # Rebuild the index > # Dump the index table > The index table row should have the null value for the covered column. > However, it has the not null value written at step 2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5535) Index rebuilds via UngroupedAggregateRegionObserver should replay delete markers
[ https://issues.apache.org/jira/browse/PHOENIX-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-5535: --- Attachment: PHOENIX-5535.master.002.patch > Index rebuilds via UngroupedAggregateRegionObserver should replay delete > markers > > > Key: PHOENIX-5535 > URL: https://issues.apache.org/jira/browse/PHOENIX-5535 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.0.0, 4.14.3 >Reporter: Kadir OZDEMIR >Assignee: Kadir OZDEMIR >Priority: Blocker > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5535.master.001.patch, > PHOENIX-5535.master.002.patch > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently index rebuilds for global index tables are done on the server side. > Phoenix client generates an aggregate plan using ServerBuildIndexCompiler to > scan every data table row on the server side . This complier sets the scan > attributes so that the row mutations that are scanned by > UngroupedRegionObserver are then replayed on the data table so that index > table rows are rebuilt. During this replay, data table row updates are > skipped and only index table row are updated. > Phoenix allows column entries to have null values. Null values are > represented by HBase column delete marker. This means that index rebuild must > replay these delete markers along with put mutations. In order to do that > ServerBuildIndexCompiler should use raw scans but currently it does use > regular scans. This leads incorrect index rebuilds when null values are used. > A simple test where a data table with one global index with a covered column > that can take null value is sufficient to reproduce this problem. > # Create a data table with columns a, b, and c where a is the primary key > and c can have null value > # Write one row with not null values > # Overwrite the covered column with null (i.e., set it to null) > # Create an index on the table where b is the secondary key and c is covered > column > # Rebuild the index > # Dump the index table > The index table row should have the null value for the covered column. > However, it has the not null value written at step 2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-5537) Phoenix-4701 made hard coupling between phoenix.log.level and getting request metrics.
Daniel Wong created PHOENIX-5537:
Summary: Phoenix-4701 made hard coupling between phoenix.log.level
and getting request metrics.
Key: PHOENIX-5537
URL: https://issues.apache.org/jira/browse/PHOENIX-5537
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.15.0
Reporter: Daniel Wong
Fix For: 4.15.1
Phoenix-4701 made hard coupling between phoenix.log.level and getting request
metrics. For users who do not want to enable system to log this causes a
regression from earlier behavior where metrics were populated. FYI [~ankit]
{code:java}
public OverAllQueryMetrics(boolean isRequestMetricsEnabled, LogLevel
connectionLogLevel) { public OverAllQueryMetrics(boolean
isRequestMetricsEnabled, LogLevel connectionLogLevel) { queryWatch = new
MetricsStopWatch(WALL_CLOCK_TIME_MS.isLoggingEnabled(connectionLogLevel));
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (PHOENIX-5536) Could nOT Reseek StoreFileScanner [APACHE PHOENIX ]
priya shri created PHOENIX-5536: --- Summary: Could nOT Reseek StoreFileScanner [APACHE PHOENIX ] Key: PHOENIX-5536 URL: https://issues.apache.org/jira/browse/PHOENIX-5536 Project: Phoenix Issue Type: Bug Affects Versions: 4.14.1 Reporter: priya shri Fix For: 4.14.1 when i am trying to fetch data from phoenix it through error could not reseek StoreFileScanner [HFile Scanner for reader reader= hdfs://[Hfile path]. i could not able to find the key point for this problem. i also checked hbase region servers and hdfs both are in healthy condition but phoenix could not be able to read the data. please help me out if anyone else face the same issue, or what is the so;ution for this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
