Horton

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

Alena Rybakina <lena.ribackina@yandex.ru>

View thread View on postgr.es
From: Alena Rybakina <lena.ribackina@yandex.ru>
To: tender wang <tndrwang@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@lists.postgresql.org, David Rowley <dgrowleyml@gmail.com>, Richard Guo <guofenglinux@gmail.com>
Date: 2023-10-18T13:44:08Z
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

Commits

  1. Fix unstable test in select_parallel.sql

  2. Consider materializing the cheapest inner path in parallel nestloop

  3. doc PG 17 relnotes: adjust IN wording

  4. Support parallel joins, and make related improvements.