Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Xy416-0006mW-S5 for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Dec 2014 19:30:44 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Xy416-0007g1-7t for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Dec 2014 19:30:44 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Xy415-0007fv-9y for pgsql-hackers@postgresql.org; Mon, 08 Dec 2014 19:30:43 +0000 Received: from 01.zmailcloud.com ([192.198.85.104] helo=mx-out-1.zmailcloud.com) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Xy411-0004Aa-R7 for pgsql-hackers@postgresql.org; Mon, 08 Dec 2014 19:30:41 +0000 Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 2902D565832; Mon, 8 Dec 2014 13:30:39 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 16CB6A043B; Mon, 8 Dec 2014 13:30:39 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0-Qr4WNBIkr; Mon, 8 Dec 2014 13:30:39 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E854DA0455; Mon, 8 Dec 2014 13:30:38 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D0596A043B; Mon, 8 Dec 2014 13:30:38 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GGpGxtpKMTUk; Mon, 8 Dec 2014 13:30:38 -0600 (CST) Received: from [172.47.23.103] (50-0-89-106.dsl.dynamic.fusionbroadband.com [50.0.89.106]) by smtp-out-1.01.com (Postfix) with ESMTPSA id B764CA0454; Mon, 8 Dec 2014 13:30:37 -0600 (CST) Message-ID: <5485FC56.7000904@agliodbs.com> Date: Mon, 08 Dec 2014 11:30:30 -0800 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Robert Haas , Amit Kapila CC: Amit Langote , Andres Freund , Alvaro Herrera , Bruce Momjian , Pg Hackers Subject: Re: On partitioning References: <20140829155607.GF7705@eldon.alvh.no-ip.org> <053501cffa30$ecdf8700$c69e9500$@lab.ntt.co.jp> <066501cffd52$3d919390$b8b4bab0$@lab.ntt.co.jp> <032601d00471$ea6f4280$bf4dc780$@lab.ntt.co.jp> <04da01d00917$2dde1010$899a3030$@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) 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 On 12/08/2014 11:05 AM, Robert Haas wrote: > I guess I'm in disagreement with you - and, perhaps - the majority on > this point. I think that ship has already sailed: partitions ARE > tables. We can try to make it less necessary for users to ever look > at those tables as separate objects, and I think that's a good idea. > But trying to go from a system where partitions are tables, which is > what we have today, to a system where they are not seems like a bad > idea to me. If we make a major break from how things work today, > we're going to end up having to reimplement stuff that already works. I don't thing its feasible to drop inheritance partitioning at this point; too many user exploit a lot of peculiarities of that system which wouldn't be supported by any other system. So any new partitioning system we're talking about would be *in addition* to the existing system. Hence my prior email trying to make sure that a new proposed system is sufficiently different from the existing one to be worthwhile. > Besides, I haven't really seen anyone propose something that sounds > like a credible alternative. If we could make partition objects > things that the storage layer needs to know about but the query > planner doesn't need to understand, that'd be maybe worth considering. > But I don't see any way that that's remotely feasible. On the other hand, as long as partitions exist exclusively at the planner layer, we can't fix the existing major shortcomings of inheritance partitioning, such as its inability to handle expressions. Again, see previous. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers