Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1as4y8-0002k1-2W for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Apr 2016 08:55:44 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1as4y7-0002dK-LA for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Apr 2016 08:55:43 +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 1as4y3-0002Xs-BG for pgsql-hackers@postgresql.org; Mon, 18 Apr 2016 08:55:39 +0000 Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]) by magus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1as4xz-0007iU-VD for pgsql-hackers@postgresql.org; Mon, 18 Apr 2016 08:55:38 +0000 Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id u3I8tRKM004013; Mon, 18 Apr 2016 17:55:27 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id B3CED5F611; Mon, 18 Apr 2016 17:55:27 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 9B83A5F58E; Mon, 18 Apr 2016 17:55:27 +0900 (JST) Received: from [127.0.0.1] (unknown [129.60.241.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTP id 92AA4400B4D; Mon, 18 Apr 2016 17:55:27 +0900 (JST) Subject: Re: Declarative partitioning References: <55D3093C.5010800@lab.ntt.co.jp> <56C55973.80309@lab.ntt.co.jp> <56CD6598.4090302@lab.ntt.co.jp> <56DE2D4B.1040001@lab.ntt.co.jp> <56DF74F0.7060404@lab.ntt.co.jp> <56F0AC96.2010303@lab.ntt.co.jp> <57106F9E.3000309@lab.ntt.co.jp> <57146A6C.2010801@lab.ntt.co.jp> From: Amit Langote Message-ID: <5714A0F3.1000606@lab.ntt.co.jp> Date: Mon, 18 Apr 2016 17:55:15 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Ashutosh Bapat Cc: Robert Haas , Alexander Korotkov , Amit Langote , Corey Huinker , Pg Hackers X-TM-AS-MML: disable X-Pg-Spam-Score: -3.6 (---) 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 2016/04/18 15:33, Ashutosh Bapat wrote: >> For time being, I will leave this as yet unaddressed (I am thinking about >> what is reasonable to do for this also considering Robert's comment). Is >> that OK? >> > > Right now EXPLAIN of select * from t1, where t1 is partitioned table shows > Append > -> Seq Scan on t1 > -> Seq scan on partition 1 > -> seq scan on partition 2 > ... > which shows t1 as well as all the partitions on the same level. Users might > have accepted that for inheritance hierarchy but for partitioning that can > be confusing, esp. when all the error messages and documentation indicate > that t1 is an empty (shell?) table. Instead showing it like > Append for t1 -- (essentially show that this is Append for partitioned > table t1, exact text might vary) > -> Seq scan on partition 1 > -> .... > would be more readable. Similarly if we are going to collapse all the > Append hierarchy, it might get even more confusing. Listing all the > intermediate partitioned tables as Seq Scan on them would be confusing for > the reasons mentioned above, and not listing them might make user wonder > about the reasons for their disappearance. I am not sure what's the > solution their. Yes, things remain confusing with Append plans for partitioned tables. Note that currently if an internal partition doesn't show up, none of its partitions do (given the way CHECK constraints are generated for each table in the partition tree). >> OK, I will address this in the next version. One question though: should >> foreign table be only allowed to be leaf partitions (ie, no PARTITION BY >> clause in CREATE FOREIGN TABLE ... PARTITION OF)? > > That seems a better way. Otherwise users might wonder whether we keep the > partitions of a foreign table on the foreign server which won't be true. Quite true. Can't assume anything other than what the FDW for a given foreign table lets us assume about what the remote table looks like. Existing FDW API allows to treat a foreign table as nothing other than regular tables at best. > But then we allow foreign tables to have local tables as children in > inheritance, so somebody from that background might find it incompatible. I > think we shouldn't let the connection between partitioning and inheritance > linger longer than necessary. I, too, think quite some about this last sentence. But I have only considered DDL yet. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers