What I am thinking is that, there "maybe" situations where a guidepost would actually be misleading. For example, if the operator configures the major compaction to run very infrequently, so out stats turn out to be not accurate compared to the latest distribution. Splitting according guide post can inadvertently generates bad split. This maybe a very rare situation and not common usage, but we should give people the option just in case.


On 3/8/13 9:32 PM, "James Taylor" <notifications@github.com> wrote:

In src/main/java/com/salesforce/phoenix/iterate/ParallelIteratorRegionSpliterFactory.java:
> + * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
> + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + ******************************************************************************/
> +package com.salesforce.phoenix.iterate;
> +
> +
> +/**
> + * Factory class for the Region Spliter used by the project.
> + *
> + * @author zhuang
> + */
> +public class ParallelIteratorRegionSpliterFactory {
> +
> +    public static ParallelIteratorRegionSpliter getSpliter() {
> +        return DefaultParallelIteratorRegionSpliter.getInstance();
When would this need to be configurable? I think, even when we use stats, the same impl will be used. We'll just have a better way to divide up intra-region instead of doing Bytes.split.

I'm fine keeping this, but wouldn't want to expose a config unless we see a use case for it.

-
Reply to this email directly or view it on GitHub <https://github.com/forcedotcom/phoenix/pull/83/files#r3307419> .