Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1Z6k-00042W-MD for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Oct 2017 14:32:38 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1e1Z6j-00071o-F8 for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Oct 2017 14:32:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e1Z6j-00071f-19 for pgsql-hackers@postgresql.org; Mon, 09 Oct 2017 14:32:37 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e1Z6b-0007k9-0A for pgsql-hackers@postgresql.org; Mon, 09 Oct 2017 14:32:36 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v99EWJ64014422; Mon, 9 Oct 2017 10:32:19 -0400 From: Tom Lane To: Alexander Korotkov cc: Haribabu Kommi , Thomas Munro , Amit Kapila , Robert Haas , Alvaro Herrera , Pg Hackers Subject: Re: Pluggable storage In-reply-to: References: <20160824182201.GA232997@alvherre.pgsql> <20161013202642.ksiuyx72gu6wgupf@alvherre.pgsql> Comments: In-reply-to Alexander Korotkov message dated "Mon, 09 Oct 2017 17:22:27 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14420.1507559539.1@sss.pgh.pa.us> Date: Mon, 09 Oct 2017 10:32:19 -0400 Message-ID: <14421.1507559539@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Alexander Korotkov writes: > For me, it's crucial point that pluggable storages should be able to have > different MVCC implementation, and correspondingly have full control over > its interactions with indexes. > Thus, it would be good if we would get consensus on that point. I'd like > other discussion participants to comment whether they agree/disagree and > why. > Any comments? TBH, I think that's a good way of ensuring that nothing will ever get committed. You're trying to draw the storage layer boundary at a point that will take in most of the system. If we did build it like that, what we'd end up with would be very reminiscent of mysql's storage engines, complete with inconsistent behaviors and varying feature sets across engines. I don't much want to go there. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers