Hi, I've returned. At Thu, 29 Jun 2017 14:08:27 +0900, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote in <63a5a01c-2967-83e0-8bbf-c981404f5...@lab.ntt.co.jp> > Hi, > > On 2017/06/29 13:45, Kyotaro HORIGUCHI wrote: > > Thank you for looking this. > > > > At Wed, 28 Jun 2017 10:23:54 +0200, Antonin Houska wrote: > >> Can you please explain this part of make_append() ? > >> > >> /* Currently async on partitioned tables is not available */ > >> Assert(nasyncplans == 0 || partitioned_rels == NIL); > >> > >> I don't think the output of Append plan is supposed to be ordered even if > >> the > >> underlying relation is partitioned. Besides ordering, is there any other > >> reason not to use the asynchronous execution? > > When making an Append for a partitioned table, among the arguments passed > to make_append(), 'partitioned_rels' is a list of RT indexes of > partitioned tables in the inheritance tree of which the aforementioned > partitioned table is the root. 'appendplans' is a list of subplans for > scanning the leaf partitions in the tree. Note that the 'appendplans' > list contains no members corresponding to the partitioned tables, because > we don't need to scan them (only leaf relations contain any data). > > The point of having the 'partitioned_rels' list in the resulting Append > plan is so that the executor can identify those relations and take the > appropriate locks on them.
Amit, thank you for the detailed explanation. I understand what it is and that just ignoring it is enough, then confirmed that actually works as before. I'll then adresss Antonin's comments tomorrow. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers