Sean Johnston <sean.johns...@edgeintelligence.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