Hello,
> > 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.
>
Thanks for testing.
> 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.
>
Indeed, we should not do that from the viewpoint of cost-effectiveness.
I think we can ignore the duplicate processing considering it doesn't
happen in all cases.
> In short, I propose to get this done as the patch I posted in
> https://postgr.es/m/20190806133053.GA23706@alvherre.pgsql
>
I agree with your proposal. Also, I confirmed a default partition was pruned
as expected with your patch.
--
Best regards,
Yuzuko Hosoya
NTT Open Source Software Center