paths in partitions of a dummy partitioned table

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: paths in partitions of a dummy partitioned table
Date: 2017-07-06 15:35:21
Message-ID: CAFjFpRd5+zroxY7UMGTR2M=rjBV4aBOCxQg3+1rBmTPLK5mpDg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
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.

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?

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Attachment Content-Type Size
pg_dummy_part_table.patch text/x-patch 1.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2017-07-06 16:20:39 Re: More race conditions in logical replication
Previous Message Petr Jelinek 2017-07-06 15:33:25 Re: More race conditions in logical replication