On Fri, Apr 7, 2023 at 09:55:00PM -0400, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > What I don't want is an error-prone setup where administrators have to
> > remember what the per-server settings are. Based on your suggestion,
> > let's allow CREATE SERVER to have an option 'enable_async_aggregate' (is
> > that the right name?), which defaults to 'true' for _all_ servers, even
> > those that don't support async aggregates.
>
> Uh, what? Why would we not be able to tell from the remote server's
> version number whether it has this ability?
That was covered here:
https://www.postgresql.org/message-id/ZC95C0%2BPVhVP3iax%40momjian.us
I think we have three possible cases for aggregate pushdown to FDWs:
1) Postgres built-in aggregate functions
2) Postgres user-defined & extension aggregate functions
3) aggregate functions calls to non-PG FDWs
Your patch handles #1 by checking that the FDW Postgres version is the
--> same as the calling Postgres version. However, it doesn't check for
--> extension versions, and frankly, I don't see how we could implement that
--> cleanly without significant complexity.
The issue is not a mismatch of postgres_fdw versions but the extension
versions and whether the partial aggregate functions exist on the remote
side, e.g., something like a PostGIS upgrade.
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Embrace your flaws. They make you human, rather than perfect,
which you will never be.
