[
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)
