Horton

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

Tomas Vondra <tomas.vondra@2ndquadrant.com>

View thread View on postgr.es
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>
Date: 2019-09-28T23:00:49Z
Lists: pgsql-hackers 
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

Commits

  1. Further adjustments to Hashagg EXPLAIN ANALYZE output

  2. Rework EXPLAIN format for incremental sort

  3. Fix typos and improve incremental sort comments

  4. Stabilize incremental_sort tests

  5. Minor improvements in Incremental Sort explain

  6. Consider Incremental Sort paths at additional places

  7. Fix representation of SORT_TYPE_STILL_IN_PROGRESS.

  8. Fix failures in incremental_sort due to number of workers

  9. Fix show_incremental_sort_info with force_parallel_mode

  10. Implement Incremental Sort

  11. Fix handling of "Subplans Removed" field in EXPLAIN output.

  12. Fix EXPLAIN (SETTINGS) to follow policy about when to print empty fields.

  13. Ensure plpgsql result tuples have the right composite type marking.

  14. Propagate sort instrumentation from workers back to leader.

  15. Make new regression test case parallel-safe, and improve its output.

  16. Push limit through subqueries to underlying sort, where possible.

  17. Fix inappropriate printing of never-measured times in EXPLAIN.

  18. Fix some infelicities in EXPLAIN output for parallel query plans.