[ https://issues.apache.org/jira/browse/PHOENIX-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16236638#comment-16236638 ]
James Taylor commented on PHOENIX-4333: --------------------------------------- Two other corner case: # Handle the case where there's a single region. In that case, we can use the time estimate from the single row we have in gps table. # Handle case where there's a guidepost in the first region, but it's *before* the startKey. We'll need to tweak this loop to stop first slightly sooner (when we're past the start key of the first region) so we know if there's a guidepost in the first region. If we enter the loop, then we have a gps for that region. Note too there are a couple of minor changes here that make sense to make, such as setting intersectWithGuidePosts and not checking the key length each time through the loop since it's not changing. {code} int startRegionIndex = regionIndex; boolean gpsForFirstRegion = false; try { if (gpsSize > 0) { stream = new ByteArrayInputStream(guidePosts.get(), guidePosts.getOffset(), guidePosts.getLength()); input = new DataInputStream(stream); decoder = new PrefixByteDecoder(gps.getMaxLength()); try { byte[] firstRegionStartKey = regionLocations.get(regionIndex).getRegionInfo().getStartKey(); if (firstRegionStartKey.getLength() > 0) { // Walk guideposts until we're past the first region start key while (firstRegionStartKey.compareTo(currentGuidePost = PrefixByteCodec.decode(decoder, input)) >= 0) { gpsForFirstRegion = true; minGuidePostTimestamp = Math.min(estimateTs, gps.getGuidePostTimestamps()[guideIndex]); guideIndex++; } // Continue walking guideposts until we get past the currentKey while (currentKey.compareTo(currentGuidePost = PrefixByteCodec.decode(decoder, input)) >= 0) { minGuidePostTimestamp = Math.min(estimateTs, gps.getGuidePostTimestamps()[guideIndex]); guideIndex++; } } } catch (EOFException e) { // expected. Thrown when we have decoded all guide posts. intersectWithGuidePosts = false; } } {code} # Then we'll want to consider {{gpsForFirstRegion}} in our setting of {{gpsAvailableForAllRegions}}. This would be necessary if the currentKey (i.e. the start key) is after the gps, but before the endKey. {code} // We have a guide post in the region if the above loop was entered // or if the current key is less than the region end key (since the loop // may not have been entered if our scan end key is smaller than the // first guide post in that region). gpsAvailableForAllRegions &= currentKeyBytes != initialKeyBytes || ( gpsForFirstRegion && regionIndex == startRegionIndex ) || ( endKey == stopKey && // If not comparing against region boundary ( endRegionKey.length == 0 || // then check if gp is in the region currentGuidePost.compareTo(endRegionKey) < 0) ); {code} > Stats - Incorrect estimate when stats are updated on a tenant specific view > --------------------------------------------------------------------------- > > Key: PHOENIX-4333 > URL: https://issues.apache.org/jira/browse/PHOENIX-4333 > Project: Phoenix > Issue Type: Bug > Affects Versions: 4.12.0 > Reporter: Mujtaba Chohan > Assignee: Samarth Jain > Priority: Major > Attachments: PHOENIX-4333_test.patch, PHOENIX-4333_v1.patch, > PHOENIX-4333_v2.patch > > > Consider two tenants A, B with tenant specific view on 2 separate > regions/region servers. > {noformat} > Region 1 keys: > A,1 > A,2 > B,1 > Region 2 keys: > B,2 > B,3 > {noformat} > When stats are updated on tenant A view. Querying stats on tenant B view > yield partial results (only contains stats for B,1) which are incorrect even > though it shows updated timestamp as current. -- This message was sent by Atlassian JIRA (v6.4.14#64029)