Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

From: Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru>
To: tender wang <tndrwang(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, David Rowley <dgrowleyml(at)gmail(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>
Subject: Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Date: 2023-10-18 13:44:08
Message-ID: 0468a156-92c4-4b2b-8475-a573bb8691e1@yandex.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

Thank you for your work on the subject.

I reviewed your patch and found that your commit message does not fully
explain your code, in addition, I found several spelling mistakes.

I think it's better to change to:

With parallel seqscan, we should consider materializing the cheapest
inner path in
case of nested loop if it doesn't contain a unique node or it is unsafe
to use it in a subquery.

Besides, I couldn't understand why we again check that material path is
safe?

if (matpath != NULL && matpath->parallel_safe)
            try_partial_nestloop_path(root, joinrel, outerpath, matpath,
                                      pathkeys, jointype, extra);

--
Regards,
Alena Rybakina

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2023-10-18 14:03:06 Re: Query execution in Perl TAP tests needs work
Previous Message Vik Fearing 2023-10-18 13:04:13 Re: run pgindent on a regular basis / scripted manner