On Mon, Sep 9, 2019 at 5:55 PM Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > The "patched" column means all developer GUCs disabled, so it's expected > to produce the same plan as master (and it is). And then there's one > column for each developer GUC. If the column is just TRUE it means the > GUC does not affect any of the synthetic queries. There are 4 of them: > > - devel_add_paths_to_grouping_rel_parallel > - devel_create_partial_grouping_paths > - devel_gather_grouping_paths > - devel_standard_join_search > > The places controlled by those GUCs are either useless, or the query > affected by them is not included in the list of queries.
I'd previously found (in my reverse engineering efforts) the query: select * from tenk1 t1 join tenk1 t2 on t1.hundred = t2.hundred join tenk1 t3 on t1.hundred = t3.hundred order by t1.hundred, t1.twenty limit 50; can change plans to use incremental sort when generate_useful_gather_paths() is added to standard_join_search(). Specifically, we get a merge join between t1 and t3 as the top level (besides limit) node where the driving side of the join is a gather merge with incremental sort. This does rely on these gucs set in the test harness: set local max_parallel_workers_per_gather=4; set local min_parallel_table_scan_size=0; set local parallel_tuple_cost=0; set local parallel_setup_cost=0; So I think we can reduce the number of unused gucs to 3. James
