Re: ORDER BY pushdowns seem broken in postgres_fdw
От | Ronan Dunklau |
---|---|
Тема | Re: ORDER BY pushdowns seem broken in postgres_fdw |
Дата | |
Msg-id | 5578227.HAYmEhll7C@aivenronan обсуждение исходный текст |
Ответ на | Re: ORDER BY pushdowns seem broken in postgres_fdw (Ronan Dunklau <ronan.dunklau@aiven.io>) |
Ответы |
Re: ORDER BY pushdowns seem broken in postgres_fdw
|
Список | pgsql-hackers |
Le mercredi 21 juillet 2021, 11:05:14 CEST Ronan Dunklau a écrit : > 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. > In fact the support for generating the correct USING clause was inexistent too, so that needed a bit more work. The attached patch does the following: - verify the opfamily is shippable to keep pathkeys - generate a correct order by clause using the actual operator. The second part needed a bit of refactoring: the find_em_expr_for_input_target and find_em_expr_for_rel need to return the whole EquivalenceMember, because we can't know the type used by the opfamily from the expression (example: the expression could be of type intarray, but the type used by the opfamily could be anyarray). I also moved the "USING <operator>"' string generation to a separate function since it's now used by appendAggOrderBy and appendOrderByClause. The find_em_expr_for_rel is exposed in optimizer/paths.h, so I kept the existing function which returns the expr directly in case it is used out of tree. -- Ronan Dunklau
Вложения
В списке pgsql-hackers по дате отправления: