Hello, At Thu, 6 Jul 2017 21:05:21 +0530, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote in <CAFjFpRd5+zroxY7UMGTR2M=rjbv4abocxqg3+1rbmtplk5m...@mail.gmail.com> > If a partitioned table is proven dummy, set_rel_pathlist() doesn't mark the > partition relations dummy and thus doesn't set any (dummy) paths in the > partition relations. The lack of paths in the partitions means that we can
A parent won't be proven dummy directly but be a dummy rel (means IS_DUMMY_REL(rel) returns true) if no child is attached as the result of constarint exlusion. > not use partition-wise join while joining this table with some other similarly > partitioned table as the partitions do not have any paths that child-joins can > use. This means that we can not create partition relations for such a join and > thus can not consider the join to be partitioned. This doesn't matter much > when > the dummy relation is the outer relation, since the resultant join is also > dummy. But when the dummy relation is inner relation, the resultant join is > not > dummy and can be considered to be partitioned with same partitioning scheme as > the outer relation to be joined with other similarly partitioned table. Not > having paths in the partitions deprives us of this future optimization. > Without partition-wise join, not setting dummy paths in the partition > relations > makes sense, since those do not have any use. But with partition-wise join > that > changes. Of course for inner-joins and even for outer-joins, there's no point in considering the children of a dummy parent as a side of a join. For what reason, or in what case does partition-wise join need to consider children of a proven-dummy parent? > If we always mark the partitions dummy, that effort may get wasted if the > partitioned table doesn't participate in the partition-wise join. A possible > solution would be to set the partitions dummy when only the partitioned table > participates in the join, but that happens during make_join_rel(), much after > we have set up the simple relations. So, I am not sure, whether that's a good > option. But I am open to suggestions. > > What if we always mark the partition relations of a dummy partitioned table > dummy? I tried attached path on a thousand partition table, the planning time > increased by 3-5%. That doesn't look that bad for a thousand partitions. > > Any other options/comments? Since I don't understand the meaning of the patch, the comments below are just from a micro-viewpoint. - if (IS_DUMMY_REL(rel)) + if (IS_DUMMY_REL(rel) && !rte->inh) In set_rel_pathlist, if want to exlude the inh==true case from the first if, just inverting the first and second if caluses would be enough, like this. | if (rte->inh) | set_append_rel_pathlist(root, rel, rti, rte); | else if (IS_DUMMY_REL(rel)) | /* We already proved the relation empty, so nothing more to do */ + if (IS_DUMMY_REL(rel)) + set_dummy_rel_pathlist(childrel); This is equivalent of just returning before looking over append_rel_list when rel is a dummy. It doesn't seem to me to add marked-as-dummy children to a dummy parent. (I understand that is the objective of this patch.) # Maybe I'm looking a different version of the source code, or # I'm terriblly misunderstanding something.. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
