Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > (2019/02/23 0:21), Antonin Houska wrote: > > Etsuro Fujita<fujita.ets...@lab.ntt.co.jp> wrote: > > >>> (2019/02/08 2:04), Antonin Houska wrote: > >>>> * regression tests: I think test(s) should be added for queries that have > >>>> ORDER BY clause but do not have GROUP BY (and also no LIMIT / OFFSET) > >>>> clause. I haven't noticed such tests. > > >> I noticed that such queries would be processed by what we already have for > >> sort pushdown (ie, add_paths_with_pathkeys_for_rel()). I might be missing > >> something, though. > > > > What about an ORDER BY expression that contains multiple Var nodes? For > > example > > > > SELECT * FROM foo ORDER BY x + y; > > > > I think the base relation should not be able to generate paths with the > > corresponding pathkeys, since its target should (besides PlaceHolderVars, > > which should not appear in the plan of this simple query at all) only emit > > individual Vars. > > Actually, add_paths_with_pathkeys_for_rel() generates such pre-sorted paths > for the base relation, as shown in the below example using HEAD without the > patchset proposed in this thread: > > postgres=# explain verbose select a+b from ft1 order by a+b; > QUERY PLAN > -------------------------------------------------------------------------- > Foreign Scan on public.ft1 (cost=100.00..200.32 rows=2560 width=4) > Output: (a + b) > Remote SQL: SELECT a, b FROM public.t1 ORDER BY (a + b) ASC NULLS LAST > (3 rows) > > I think it is OK for that function to generate such paths, as tlists for such > paths would be adjusted in apply_scanjoin_target_to_paths(), by doing > create_projection_path() to them.
I've just checked it. The FDW constructs the (a + b) expression for the ORDER BY clause on its own. It only needs to find the input vars in the relation target. > Conversely, it appears that add_foreign_ordered_paths() added by the patchset > would generate such pre-sorted paths *redundantly* when the input_rel is the > final scan/join relation. Will look into that. Currently I have no idea how to check the plan created by FDW at the UPPERREL_ORDERED stage, except for removing the sort from the UPPERREL_GROUP_AGG stage as I proposed here: https://www.postgresql.org/message-id/11807.1549564431%40localhost -- Antonin Houska https://www.cybertec-postgresql.com
