From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: James Coleman <jtc331@gmail.com>
Cc: Rafia Sabih <rafia.pghackers@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Shaun Thomas <shaun.thomas@2ndquadrant.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Date: Sun, 29 Sep 2019 01:00:49 +0200
Message-ID: <20190928230049.k4l2mayun7jomhxy@development> (raw)
In-Reply-To: <CAAaqYe-L4a2mj=AqguVjdkf65LZ772C-GbKgAj7CQro8rftXBg@mail.gmail.com>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, jtc331@gmail.com, rafia.pghackers@gmail.com, pg@bowt.ie, simon@2ndquadrant.com, shaun.thomas@2ndquadrant.com, 9erthalion6@gmail.com, a.korotkov@postgrespro.ru, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org, alvherre@2ndquadrant.com
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
In-Reply-To: <20190928230049.k4l2mayun7jomhxy@development>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox