Laurenz Albe <laurenz.albe@cybertec.at> writes:
> Thanks for the pointer. Perhaps something like the attached?
> The changes in "CreatePartitionPruneState" make my test case work,
> but they cause a difference in the regression tests, which would be
> intended if we have no partition pruning with plain EXPLAIN.
Hmm, so I see (and the cfbot entry for this patch is now all red,
because you didn't include that diff in the patch).
I'm not sure if we can get away with that behavioral change.
People are probably expecting the current behavior for existing
cases.
I can think of a couple of possible ways forward:
* Fix things so that the generic parameters appear to have NULL
values when inspected during executor startup. I'm not sure
how useful that'd be though. In partition-pruning cases that'd
lead to EXPLAIN (GENERIC_PLAN) showing the plan with all
partitions pruned, other than the one for NULL values if there
is one. Doesn't sound too helpful.
* Invent another executor flag that's a "stronger" version of
EXEC_FLAG_EXPLAIN_ONLY, and pass that when any generic parameters
exist, and check it in CreatePartitionPruneState to decide whether
to do startup pruning. This avoids changing behavior for existing
cases, but I'm not sure how much it has to recommend it otherwise.
Skipping the startup prune step seems like it'd produce misleading
results in another way, ie showing too many partitions not too few.
This whole business of partition pruning dependent on the
generic parameters is making me uncomfortable. It seems like
we *can't* show a plan that is either representative of real
execution or comparable to what you get from more-traditional
EXPLAIN usage. Maybe we need to step back and think more.
regards, tom lane