Re: Split and distribute regions of SYSTEM.STATS table

For stats, what do you have your guidepost width set to? Do you only have a single physical table? We've found that a value of 300MB still provides a good enough granularity to get good bytes scanned estimates. We're currently using an HBase API to update stats atomically. We could easily make it

Re: Split and distribute regions of SYSTEM.STATS table

If all stats for given table should be on the same region there is no benefits on splitting. Another question: is it ok to set 'IN_MEMORY' => 'true' for CF of SYSTEM.* tables? > On 20 Apr 2018, at 23:39, James Taylor wrote: > > Thanks for bringing this to our

Re: Split and distribute regions of SYSTEM.STATS table

Thanks for bringing this to our attention. There's a bug here in that the SYSTEM.STATS table has a custom split policy that prevents splitting from occurring (PHOENIX-4700). We'll get a fix out in 4.14, but in the meantime it's safe to split the table, as long as all stats for a given table are on

Re: Split and distribute regions of SYSTEM.STATS table

Thanks for bringing this to our attention. There's a bug here in that the SYSTEM.STATS On Wed, Apr 18, 2018 at 9:59 AM, Batyrshin Alexander <0x62...@gmail.com> wrote: > Hello, > I've discovered that SYSTEM.STATS has only 1 region with size 3.25 GB. Is > it ok to split it and distribute over

Split and distribute regions of SYSTEM.STATS table

Hello, I've discovered that SYSTEM.STATS has only 1 region with size 3.25 GB. Is it ok to split it and distribute over different region servers?