Re: Asymmetric partition-wise JOIN

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Asymmetric partition-wise JOIN
Дата
Msg-id CAExHW5tr0mdEzjGth4mFNPcOBxrU=VfH5zhakg9RKeW5HZq5ng@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Asymmetric partition-wise JOIN  (Andrei Lepikhov <a.lepikhov@postgrespro.ru>)
Ответы Re: Asymmetric partition-wise JOIN  (Andrei Lepikhov <a.lepikhov@postgrespro.ru>)
Re: Asymmetric partition-wise JOIN  (Andrei Lepikhov <lepihov@gmail.com>)
Список pgsql-hackers
On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
>
> > But the clauses of A parameterized by P will produce different
> > translations for each of the partitions. I think we will need
> > different RelOptInfos (for A) to store these translations.
>
> Does the answer above resolved this issue?

May be. There are other problematic areas like EvalPlanQual, Rescans,
reparameterised paths which can blow up if we use the same RelOptInfo
for different scans of the same relation. It will be good to test
those. And also A need not be a simple relation; it could be join as
well.

>
> > The relid is also used to track the scans at executor level. Since we
> > have so many scans on A, each may be using different plan, we will
> > need different ids for those.
>
> I don't understand this sentence. Which way executor uses this index of
> RelOptInfo ?

See Scan::scanrelid

--
Best Wishes,
Ashutosh Bapat



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

Предыдущее
От: Andrei Lepikhov
Дата:
Сообщение: Re: Oversight in reparameterize_path_by_child leading to executor crash
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: RFC: Logging plan of the running query