Thread
Commits
-
Fix deparsing of Consts in postgres_fdw ORDER BY
- 9301e0f416d1 12.19 landed
- 20b85b3da6f8 13.15 landed
- 628c3f2e17fe 14.12 landed
- ab64b275ad8f 15.7 landed
- 6a9e2cb2b457 16.3 landed
- c399248b3b44 17.0 landed
-
BUG #18381: Invalid query generated by postgres_fdw with UNION ALL and ORDER BY
The Post Office <noreply@postgresql.org> — 2024-03-07T10:22:33Z
The following bug has been logged on the website: Bug reference: 18381 Logged by: Michal Kleczek Email address: michal@kleczek.org PostgreSQL version: 16.2 Operating system: Linux Description: The following query: SELECT * FROM ( SELECT 2023 AS year, * FROM remote_table_1 UNION ALL SELECT 2022 AS year, * FROM remote_table_2 ) ORDER BY year DESC; yields the following remote query: SELECT [columns] FROM remote_table_1 ORDER BY 2023 DESC and subsequently fails remote execution. Not really sure where the problem is - the planner or postgres_fdw. I guess it is postgres_fdw not filtering out ordering keys. This filtering would also be pretty useful in the following scenario (which is also why I went through UNION ALL route and discovered this issue): I have a table partitioned by year, partitions are remote tables. On remote servers I have a GIST index that does not support ordering ([1]) so I would like to avoid sending ORDER BY year to remote servers. Ideally redundant ordering should be filtered out. [1] https://www.postgresql.org/message-id/B2AC13F9-6655-4E27-BFD3-068844E5DC91%40kleczek.org
-
Re: BUG #18381: Invalid query generated by postgres_fdw with UNION ALL and ORDER BY
David Rowley <dgrowleyml@gmail.com> — 2024-03-07T11:32:15Z
On Thu, 7 Mar 2024 at 23:35, PG Bug reporting form <noreply@postgresql.org> wrote: > > The following bug has been logged on the website: > > Bug reference: 18381 > Logged by: Michal Kleczek > Email address: michal@kleczek.org > PostgreSQL version: 16.2 > Operating system: Linux > Description: I see you've raised this on -hackers [1] already. Since there's already some discussion and a proposed fix there, I think it's better the discussion continues there. David [1] https://postgr.es/m/0714C8B8-8D82-4ABB-9F8D-A0C3657E7B6E@kleczek.org