From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, tender wang <tndrwang(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop() |
Date: | 2023-09-27 23:41:03 |
Message-ID: | CAApHDvpYev_vKj+gZvxOSbk4Ww_MBg5tZHzutAKmQCcTFYs2tw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 8 Sept 2023 at 09:41, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Sep 5, 2023 at 8:07 AM Richard Guo <guofenglinux(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2023-09-27 23:49:03 | Re: [PGdocs] fix description for handling pf non-ASCII characters |
Previous Message | Peter Geoghegan | 2023-09-27 23:38:51 | Re: Eager page freeze criteria clarification |