On Fri, Sep 27, 2019 at 01:50:30PM -0400, James Coleman wrote:
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.
OK. I'll try extending the set of synthetic queries in [1] to also do
soemthing like this and generate similar plans.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
