Re: Oversight in reparameterize_path_by_child leading to executor crash

Поиск
Список
Период
Сортировка
От Andrei Lepikhov
Тема Re: Oversight in reparameterize_path_by_child leading to executor crash
Дата
Msg-id 4f06fbf2-9892-4e66-b840-dee37536916b@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Oversight in reparameterize_path_by_child leading to executor crash  (Richard Guo <guofenglinux@gmail.com>)
Ответы Re: Oversight in reparameterize_path_by_child leading to executor crash  (Richard Guo <guofenglinux@gmail.com>)
Список pgsql-hackers
On 23/8/2023 12:37, Richard Guo wrote:
> To fix it we may need to modify RelOptInfos for Path, BitmapHeapPath,
> ForeignPath and CustomPath, and modify IndexOptInfos for IndexPath.  It
> seems that that is not easily done without postponing reparameterization
> of paths until createplan.c.
> 
> Attached is a patch which is v5 + fix for this new issue.

Having looked into the patch for a while, I couldn't answer to myself 
for some stupid questions:
1. If we postpone parameterization until the plan creation, why do we 
still copy the path node in the FLAT_COPY_PATH macros? Do we really need it?
2. I see big switches on path nodes. May it be time to create a 
path_walker function? I recall some thread where such a suggestion was 
declined, but I don't remember why.
3. Clause changing is postponed. Why does it not influence the 
calc_joinrel_size_estimate? We will use statistics on the parent table 
here. Am I wrong?

-- 
regards,
Andrey Lepikhov
Postgres Professional




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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: pg_logical_emit_message() misses a XLogFlush()
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: pg_upgrade's interaction with pg_resetwal seems confusing