Re: Runtime pruning problem

On 2019/04/21 15:25, David Rowley wrote:
> On Fri, 19 Apr 2019 at 20:01, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Another approach, as I mentioned above, is to extend the hack that begins
>> in nodeAppend.c (and nodeMergeAppend.c) into explain.c, as in the
>> attached. Then:
>>
>> explain verbose select * from t1 where dt = current_date + 400 order by id;
>> QUERY PLAN
>> ───────────────────────────────────────────────────
>> Sort (cost=199.62..199.73 rows=44 width=8)
>> Output: t1_1.id, t1_1.dt
>> Sort Key: t1_1.id
>> -> Append (cost=0.00..198.42 rows=44 width=8)
>> Subplans Removed: 4
>> (5 rows)
>
> We could do that, but I feel that's making EXPLAIN tell lies, which is
> probably a path we should avoid. The lies might be fairly innocent
> today, but maintaining them over time, like any lie, might become more
> difficult. We did perform init on a subnode, the subnode might be an
> index scan, which we'd have obtained a lock on the index. It could be
> fairly difficult to explain why that is given the lack of mention of
> it in the explain output.

I had overlooked the fact that ExecInitAppend and ExecInitMergeAppend
actually perform ExecInitNode on the subplan, so on second thought, I
agree we've got to show it. Should this have been documented? The chance
that users may query for values that they've not defined partitions for
might well be be non-zero.

> The fix I was working on before heading away for Easter was around
> changing ruleutils.c to look at Plan nodes rather than PlanState
> nodes. I'm afraid that this would still suffer from showing the alias
> of the first subnode but not show it as in the explain output you show
> above, but it does allow us to get rid of the code the initialises the
> first subnode. I think that's a much cleaner way to do it.

I agree.

> I agree with Tom about the v13 part. If we were having this discussion
> this time last year, then I'd have likely pushed for a v11 fix, but
> since it's already shipped like this in one release then there's not
> much more additional harm in two releases working this way. I'll try
> and finished off the patch I was working on soon and submit to v13's
> first commitfest.

OK, I'll try to review it.

Thanks,
Amit