From: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
---|---|
To: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: ORDER BY pushdowns seem broken in postgres_fdw |
Date: | 2021-07-21 09:05:14 |
Message-ID: | 6188872.DviVyztOPx@aivenronan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le mercredi 21 juillet 2021, 04:25:00 CEST David Rowley a écrit :
> Here the test claims that it wants to ensure that the order by using
> operator(public.<^) is not pushed down into the foreign scan.
> However, unless I'm mistaken, it seems there's a completely wrong
> assumption there that the planner would even attempt that. In current
> master we don't add PathKeys for ORDER BY aggregates, why would that
> sort get pushed down in the first place?
The whole aggregate, including it's order by clause, can be pushed down so
there is nothing related to pathkeys here.
>
> If I adjust that query to something that would have the planner set
> pathkeys for, it does push the ORDER BY to the foreign server without
> any consideration that the sort operator is not shippable to the
> foreign server.
>
> Am I missing something here, or is postgres_fdw.c's
> get_useful_pathkeys_for_relation() just broken?
I think you're right, we need to add a check if the opfamily is shippable.
I'll submit a patch for that including regression tests.
Regards,
--
Ronan Dunklau
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2021-07-21 09:07:28 | Re: Using each rel as both outer and inner for JOIN_ANTI |
Previous Message | Richard Guo | 2021-07-21 08:44:53 | Re: A problem about partitionwise join |