Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)

Sean Johnston <sean(dot)johnston(at)edgeintelligence(dot)com> writes:
> Not sure if this is the right avenue to follow up on this. The patch works
> fine. However, we're working on a modified version of the postgres_fdw in
> which we're trying to push as much as possible to the remote nodes,
> including ordering and limits. The patch causes the upper paths for the
> ordering and limit to be rejected as they have no relids.

Uh, what? If you're speaking of 8cad5adb9, the only case I'm aware of
where it might be a performance issue is if you have "GROUP BY
local-expr", which seems like a pretty weird thing to need to push
to the remote side, since the local expression would be effectively
a constant on the far end.

You could imagine working around it by discarding such GROUP BY
columns in what's to be sent to the far end, and if you end up with
an empty GROUP BY clause, sending "HAVING TRUE" instead to keep the
semantics the same. But I'm uninterested in stacking yet more
klugery atop 8cad5adb9 so far as the community code is concerned.
The right way forward, as noted in the commit message, is to revert
that patch in favor of adding some API that will let the FDW control
how setrefs.c processes a ForeignScan's expressions. We just can't
do that in released branches :-(.

It's possible that we should treat this issue as an open item for v12
instead of letting it slide to v13 or later. But I think people would
only be amenable to that if you can point to a non-silly example where
failure to push the GROUP BY creates a performance issue.

regards, tom lane