Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 3B817200B52 for ; Mon, 25 Jul 2016 23:05:26 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 3A447160A67; Mon, 25 Jul 2016 21:05:26 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 8187D160A8F for ; Mon, 25 Jul 2016 23:05:25 +0200 (CEST) Received: (qmail 25125 invoked by uid 500); 25 Jul 2016 21:05:21 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 24646 invoked by uid 99); 25 Jul 2016 21:05:20 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jul 2016 21:05:20 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id AFDC52C0D5F for ; Mon, 25 Jul 2016 21:05:20 +0000 (UTC) Date: Mon, 25 Jul 2016 21:05:20 +0000 (UTC) From: "Edward Bortnikov (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-14921) Memory optimizations MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 25 Jul 2016 21:05:26 -0000 [ https://issues.apache.org/jira/browse/HBASE-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392671#comment-15392671 ] Edward Bortnikov commented on HBASE-14921: ------------------------------------------ Let me re-iterate we are respectful of everyone's contribution, and are trying to do the right thing, as much by-consensus as possible. Here's a suggestion. For the sake of the current patch, let's decouple the in-memory flush configuration from compaction configuration. The latter is a special case of the former. With compaction protected by a explicit flag, we no more need the speculative scan to predict its worthiness. The code becomes simple. In the future, we can discuss smart policies to help us eliminate this flag. [~anastas] and [~anoop.hbase], can we agree on this as base for further discussion? > Memory optimizations > -------------------- > > Key: HBASE-14921 > URL: https://issues.apache.org/jira/browse/HBASE-14921 > Project: HBase > Issue Type: Sub-task > Affects Versions: 2.0.0 > Reporter: Eshcar Hillel > Assignee: Anastasia Braginsky > Attachments: CellBlocksSegmentInMemStore.pdf, CellBlocksSegmentinthecontextofMemStore(1).pdf, HBASE-14921-V01.patch, HBASE-14921-V02.patch, HBASE-14921-V03.patch, HBASE-14921-V04-CA-V02.patch, HBASE-14921-V04-CA.patch, HBASE-14921-V05-CAO.patch, HBASE-14921-V06-CAO.patch, InitialCellArrayMapEvaluation.pdf, IntroductiontoNewFlatandCompactMemStore.pdf > > > Memory optimizations including compressed format representation and offheap allocations -- This message was sent by Atlassian JIRA (v6.3.4#6332)