Robert Haas <robertmh...@gmail.com> writes: > On Mon, Mar 14, 2016 at 1:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Yeah. An alternative definition that would support that would be to >> call the upper-path-providing callback for each FDW that's responsible >> for any base relation of the query. But I think that that would often >> lead to a lot of redundant/wasted computation, and it's not clear to >> me that we can support such cases without other changes as well.
> Sure, that's fine with me. Are you going to go make these changes now? So I started looking at this, and almost immediately came to two conclusions: 1. We need to add a "PathTarget *" parameter to create_foreignscan_path. The hard-wired assignment that's in there now, pathnode->path.pathtarget = &(rel->reltarget); is sufficient for scan and join paths, but it doesn't work at all for upper relations because we don't put anything in their reltarget fields. We could do so, but it's still problematic because there will be situations where non-topmost Paths associated with an upperrel have other targets than what topmost Paths do. This is true today for set-operation Paths and WindowAgg Paths, and I think possibly other cases as well (such as inserted projection nodes). We could possibly insist on creating a separate upperrel for every distinct target that's used by intermediate levels of Path in these trees, but that seems kinda pointless to me, at least for now. Really the best answer is to let FDWs have control of it. And it's not like we've never whacked this function's API around before. 2. I was being way too cycle-miserly when I decided to make RelOptInfo.reltarget be an embedded struct rather than defining PathTarget as a regular, separate node type. I'm gonna change that before it's too late. One extra palloc per RelOptInfo is not a noticeable price, and there are too many places where this choice is resulting in notational weirdness. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers