Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ehZ1X-0000V8-Gp for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Feb 2018 10:56:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ehZ1V-0008J7-Sj for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Feb 2018 10:56:49 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ehZ1V-0008Iy-Ii for pgsql-hackers@lists.postgresql.org; Fri, 02 Feb 2018 10:56:49 +0000 Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ehZ1N-0002rs-76 for pgsql-hackers@lists.postgresql.org; Fri, 02 Feb 2018 10:56:46 +0000 Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w12AudRK018347 for ; Fri, 2 Feb 2018 19:56:39 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 319B5EA8B70; Fri, 2 Feb 2018 19:56:39 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 2716EEA8B6F; Fri, 2 Feb 2018 19:56:39 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.241.75]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 2407F400D3A; Fri, 2 Feb 2018 19:56:39 +0900 (JST) Message-ID: <5A7443DF.1010408@lab.ntt.co.jp> Date: Fri, 02 Feb 2018 19:56:31 +0900 From: Etsuro Fujita User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 Subject: Re: non-bulk inserts and tuple routing References: <8975331d-d961-cbdd-f862-fdd3d97dc2d0@lab.ntt.co.jp> <56c9f77b-830c-4652-233e-a1c5fa5a9938@lab.ntt.co.jp> <8f53a342-e0df-4fc9-7422-c3c3c601117c@lab.ntt.co.jp> <5A69A3B7.10403@lab.ntt.co.jp> <37f7cc10-def8-b2d0-615d-dfe035e7b1ee@lab.ntt.co.jp> <5A70396A.8090400@lab.ntt.co.jp> <8399fd28-07c2-3cbc-f807-f89cdf2f98f5@lab.ntt.co.jp> <5A704055.40207@lab.ntt.co.jp> In-Reply-To: <5A704055.40207@lab.ntt.co.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: 1 To: Amit Langote Cc: pgsql-hackers@lists.postgresql.org X-TM-AS-MML: disable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk (2018/01/30 18:52), Etsuro Fujita wrote: > (2018/01/30 18:39), Amit Langote wrote: >> Will wait for your comments before sending a new version then. > > Ok, I'll post my comments as soon as possible. * ExecInitPartitionResultRelInfo is called from ExecFindPartition, but we could call that another way; in ExecInsert/CopyFrom we call that after ExecFindPartition if the partition chosen by ExecFindPartition has not been initialized yet. Maybe either would be OK, but I like that because I think that would not only better divide that labor but better fit into the existing code in ExecInsert/CopyFrom IMO. * In ExecInitPartitionResultRelInfo: + /* + * Note that the entries in this list appear in no predetermined + * order as result of initializing partition result rels as and when + * they're needed. + */ + estate->es_leaf_result_relations = + lappend(estate->es_leaf_result_relations, + leaf_part_rri); Is it OK to put this within the "if (leaf_part_rri == NULL)" block? * In the same function: + /* + * Verify result relation is a valid target for INSERT. + */ + CheckValidResultRel(leaf_part_rri, CMD_INSERT); I think it would be better to leave the previous comments as-is here: /* * Verify result relation is a valid target for an INSERT. An UPDATE * of a partition-key becomes a DELETE+INSERT operation, so this check * is still required when the operation is CMD_UPDATE. */ * ExecInitPartitionResultRelInfo does the work other than the initialization of ResultRelInfo for the chosen partition (eg, create a tuple conversion map to convert a tuple routed to the partition from the parent's type to the partition's). So I'd propose to rename that function to eg, ExecInitPartition. * CopyFrom is modified so that it calls ExecSetupPartitionTupleRouting and ExecFindPartition with a mostly-dummy ModifyTableState node. I'm not sure that is a good idea. My concern about that is that might be something like a headache in future development. * The patch 0001 and 0002 are pretty small but can't be reviewed without the patch 0003. The total size of the three patches aren't that large, so I think it would be better to put those patches together into a single patch. That's all for now. I'll continue to review the patches! Best regards, Etsuro Fujita