Re: Runtime pruning problem

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Runtime pruning problem
Дата
Msg-id d33b1b06-5bfa-41bc-ca4a-c3cd9e101c6c@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Runtime pruning problem  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
On 2019/04/21 15:25, David Rowley wrote:
> On Fri, 19 Apr 2019 at 20:01, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Paul Guo
Дата:
Сообщение: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: clean up docs for v12