Can we do a mix of #2 and #3 i.e remove IncreasingToUpperBoundRegionSplitPolicy from master, and follow #3 for branch-2 and all active release branches? If it breaks any compatibility rules, then we can go with #3 for all.
On 2020/06/19 17:33:14, Andrew Purtell <apurt...@apache.org> wrote: > I vote for #3, and it should be applied to all active code lines. > > > On Fri, Jun 19, 2020 at 3:35 AM Wellington Chevreuil < > wellington.chevre...@gmail.com> wrote: > > > While going through the changes proposed on HBASE-24530, we > > observed IncreasingToUpperBoundRegionSplitPolicy > > compares hbase.hregion.max.filesize against individual stores within a > > region when deciding whether to split a region or not. For tables having > > multiple families, this can lead to regions much larger than what's > > defined by hbase.hregion.max.filesize. > > > > Current proposal on HBASE-24530 is to add an extra policy that actually > > compares the overall region size (combining all region stores sizes) > > against hbase.hregion.max.filesize, but I wonder if it really makes sense > > to keep a policy with current IncreasingToUpperBoundRegionSplitPolicy > > behaviour. Would like to hear folks opinions if we should take any of the > > below actions? > > 1) Leave IncreasingToUpperBoundRegionSplitPolicy as it is and just add the > > new policy proposed on HBASE-24530; > > 2) Make IncreasingToUpperBoundRegionSplitPolicy deprecated and remove it > > from master branch; > > 3) Change IncreasingToUpperBoundRegionSplitPolicy to actually implement the > > logic of the new policy proposed on HBASE-24530; > > > > My view is that the current IncreasingToUpperBoundRegionSplitPolicy > > behaviour is a bug, and I vote for #3. > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk >
