On 2019-Aug-06, Alvaro Herrera wrote:
> Well, if this is really all that duplicative, one thing we could do is
> run this check in get_partprune_steps_internal only if
> constraint_exclusion is a value other than on; we should achieve the
> same effect with no repetition. Patch for that is attached. However,
> if I run the server with constraint_exclusion=on, the regression test
> fail with the attached diff. I didn't look at what test is failing, but
> it seems to me that it's not really duplicative in all cases, only some.
> Therefore we can't do it.
Right ... One of the failing cases is one that was benefitting from
constraint_exclusion in the location where we were doing it previously.
I think trying to fix this problem by selectively moving where to apply
constraint exclusion would be very bug-prone, and hard to detect whether
we're missing one spot or doing it multiple times in some other cases.
So I think we shouldn't try. If this is a real problem, then we should
add a flag to the reloptinfo and set it when we've done pruning, then
do nothing if we already did it. I'm not sure that this is correct, and
I'm even less sure that it is worth the trouble.
In short, I propose to get this done as the patch I posted in
https://postgr.es/m/20190806133053.GA23706@alvherre.pgsql
Cheers
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services