Re: Problem with default partition pruning
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: hosoya.yuzuko@lab.ntt.co.jp
Cc: Langote_Amit_f8@lab.ntt.co.jp, thibaut.madelaine@dalibo.com,
imai.yoshikazu@jp.fujitsu.com, pgsql-hackers@lists.postgresql.org
Date: 2019-04-08T11:42:51Z
Lists: pgsql-hackers
At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" <hosoya.yuzuko@lab.ntt.co.jp> wrote in <00c101d4ede0$babd4390$3037cab0$@lab.ntt.co.jp> > > BTW, now I'm a bit puzzled between whether this case should be fixed by hacking on partprune.c like > > this patch does or whether to work on getting the other patch committed and expect users to set > > constraint_exclusion = on for this to behave as expected. The original intention of setting > > partition_qual in set_relation_partition_info() was for partprune.c to use it to remove useless > > arguments of OR clauses which otherwise would cause the failure to correctly prune the default partitions > > of sub-partitioned tables. As shown by the examples in this thread, the original effort was > > insufficient, which this patch aims to improve. But, it also expands the scope of partprune.c's usage > > of partition_qual, which is to effectively perform full-blown constraint exclusion without being > > controllable by constraint_exclusion GUC, which may be seen as being good or bad. The fact that it > > helps in getting partition pruning working correctly in more obscure cases like those discussed in > > this thread means it's good maybe. > > > Umm, even though this modification might be overhead, I think this problem should be solved > without setting constraint_exclusion GUC. But I'm not sure. Partition pruning and constraint exclusion are orthogonal functions. Note that the default value of the variable is CONSTRAINT_EXCLUSION_PARTITION and the behavior is not a perfect bug. So I think we can reasonably ignore constraints when constraint_exclusion is intentionally turned off. As the result I propose to move the "if(partconstr)" block in the latest patches after the constant-false block, changing the condition as "if (partconstr && constraint_exclusion != CONSTRAINT_EXCLUSION_OFF)". This make partprune reacts to constraint_exclusion the consistent way with the old-fashioned partitioning. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Don't constraint-exclude partitioned tables as much
- 815ef2f568c7 13.0 landed
-
Apply constraint exclusion more generally in partitioning
- 4e85642d935e 13.0 landed
-
Improve pruning of a default partition
- e3967a16d3a0 11.5 landed
- 86544071484a 12.0 landed
- 489247b0e615 13.0 landed
-
Doc: Fix event trigger firing table
- 44460d7017cd 13.0 cited
-
Remove obsolete nbtree insertion comment.
- 489e431ba56b 12.0 cited