Date: Sun, 29 Sep 2019 01:00:49 +0200
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: James Coleman <jtc331@gmail.com>
Cc: Rafia Sabih <rafia.pghackers@gmail.com>, Peter Geoghegan <pg@bowt.ie>,
	Simon Riggs <simon@2ndquadrant.com>,
	Shaun Thomas <shaun.thomas@2ndquadrant.com>,
	Dmitry Dolgov <9erthalion6@gmail.com>,
	Alexander Korotkov <a.korotkov@postgrespro.ru>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>,
	Alvaro Herrera <alvherre@2ndquadrant.com>
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Message-ID: <20190928230049.k4l2mayun7jomhxy@development>
References: 
 <CAAaqYe977wd4cyQno_pNBSzM4=2S8rzdxAE9kre2Vzh1JYMYpQ@mail.gmail.com>
 <CAAaqYe9VPucfA80sazxaUCsVovcfv1CYTddzB14yHJWcSe7wrg@mail.gmail.com>
 <20190720165951.m6adwbqi26bsfbjb@development>
 <CAAaqYe9szJ9=a-ayZUuLbV8rBh3YYgxtCHzdh5Mo2xMS7NL=rQ@mail.gmail.com>
 <20190721113422.hjubqs45xxpnldn7@development>
 <20190730001711.hprrcx3ntk57wuqv@development>
 <CA+FpmFfEJZ=obUpjgXO5u3T1yzqPh3CPsyfjhEN9_L31NDPHqA@mail.gmail.com>
 <20190904191710.gogtnktjbvtg5zq3@development>
 <20190909215538.42hrv6j4z5ztcft4@development>
 <CAAaqYe-L4a2mj=AqguVjdkf65LZ772C-GbKgAj7CQro8rftXBg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: 
 <CAAaqYe-L4a2mj=AqguVjdkf65LZ772C-GbKgAj7CQro8rftXBg@mail.gmail.com>
User-Agent: NeoMutt/20180716
Precedence: bulk

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.vondra@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