Re: [HACKERS] paths in partitions of a dummy partitioned table - Mailing list pgsql-hackers

Hello,

At Thu, 6 Jul 2017 21:05:21 +0530, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote in
<CAFjFpRd5+zroxY7UMGTR2M=rjBV4aBOCxQg3+1rBmTPLK5mpDg@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