Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, tender wang <tndrwang@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-09-27T23:41:03Z
Lists: pgsql-hackers
On Fri, 8 Sept 2023 at 09:41, Robert Haas <robertmhaas@gmail.com> wrote: > > On Tue, Sep 5, 2023 at 8:07 AM Richard Guo <guofenglinux@gmail.com> wrote: > > Yeah, this seems an omission in commit 45be99f8. > > It's been a while, but I think I omitted this deliberately because I > didn't really understand the value of it and wanted to keep the > planning cost down. I think the value is potentially not having to repeatedly execute some expensive rescan to the nested loop join once for each outer-side tuple. The planning cost is something to consider for sure, but it seems strange that we deemed it worthy to consider material paths for the non-parallel input paths but draw the line for the parallel/partial ones. It seems to me that the additional costs and the possible benefits are the same for both. David
Commits
-
Fix unstable test in select_parallel.sql
- 7e187a7386cc 18.0 landed
-
Consider materializing the cheapest inner path in parallel nestloop
- 22d946b0f86f 18.0 landed
-
doc PG 17 relnotes: adjust IN wording
- 8fea1bd5411b 17.0 cited
-
Support parallel joins, and make related improvements.
- 45be99f8cd5d 9.6.0 cited