Github user JamesRTaylor commented on a diff in the pull request:

    https://github.com/apache/phoenix/pull/8#discussion_r16797475
  
    --- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/iterate/DefaultParallelIteratorRegionSplitter.java
 ---
    @@ -138,14 +146,10 @@ public boolean apply(HRegionLocation location) {
             //    split each region in s splits such that:
             //    s = max(x) where s * x < t
             //
    -        // The idea is to align splits with region boundaries. If rows are 
not evenly
    -        // distributed across regions, using this scheme compensates for 
regions that
    -        // have more rows than others, by applying tighter splits and 
therefore spawning
    -        // off more scans over the overloaded regions.
    -        int splitsPerRegion = getSplitsPerRegion(regions.size());
             // Create a multi-map of ServerName to List<KeyRange> which we'll 
use to round robin from to ensure
             // that we keep each region server busy for each query.
    -        ListMultimap<HRegionLocation,KeyRange> keyRangesPerRegion = 
ArrayListMultimap.create(regions.size(),regions.size() * splitsPerRegion);;
    +        int splitsPerRegion = getSplitsPerRegion(regions.size());
    +        ListMultimap<HRegionLocation,KeyRange> keyRangesPerRegion = 
ArrayListMultimap.create(regions.size(),regions.size() * splitsPerRegion);
             if (splitsPerRegion == 1) {
                 for (HRegionLocation region : regions) {
    --- End diff --
    
    That sounds fine, but then switch region name after cf name so we can get 
the stats more easily. I think a good pk would be: <table name><cf name><region 
name>. Then use the stats name as a regular key value column with the correct 
type (i.e. VARBINARY ARRAY for guideposts). Probably cleaner to store the stats 
on the PColumnFamily instead of PTable too. You can still pass then through the 
PTableImpl constructor, but might as well break them up by CF and pass through 
the constituent parts to the PColumnFamilyImpl constructor. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

Reply via email to