From 2d1d26e5033e26f18afca9e08d594be10e1e2f0b Mon Sep 17 00:00:00 2001 From: James Coleman Date: Fri, 27 Mar 2020 11:10:21 -0400 Subject: [PATCH v42 05/12] move algorith description --- src/backend/executor/nodeIncrementalSort.c | 38 ++++++++++++---------- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/src/backend/executor/nodeIncrementalSort.c b/src/backend/executor/nodeIncrementalSort.c index 4cb7679f10..fde8822a82 100644 --- a/src/backend/executor/nodeIncrementalSort.c +++ b/src/backend/executor/nodeIncrementalSort.c @@ -24,7 +24,7 @@ * (3, 3) * (3, 7) * - * Incremental sort algorithm would split the input into the following + * An incremental sort algorithm would split the input into the following * groups, which have equal X, and then sort them by Y individually: * * (1, 5) (1, 2) @@ -49,6 +49,24 @@ * it can start producing rows early, before sorting the whole dataset, * which is a significant benefit especially for queries with LIMIT. * + * The algorithm we've implemented here is modified from the theoretical + * base described above by operating in two different modes: + * - Fetching a minimum number of tuples without checking prefix key + * group membership and sorting on all columns when safe. + * - Fetching all tuples for a single prefix key group and sorting on + * solely the unsorted columns. + * We always begin in the first mode, and employ a heuristic to switch + * into the second mode if we believe it's beneficial. + * + * Sorting incrementally can potentially use less memory, avoid fetching + * and sorting all tuples in the the dataset, and begin returning tuples + * before the entire result set is available. + * + * The hybrid mode approach allows us to optimize for both very small + * groups (where the overhead of a new tuplesort is high) and very large + * groups (where we can lower cost by not having to sort on already sorted + * columns), albeit at some extra cost while switching between modes. + * * Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * @@ -467,23 +485,7 @@ switchToPresortedPrefixMode(PlanState *pstate) * ExecIncrementalSort * * Assuming that outer subtree returns tuple presorted by some prefix - * of target sort columns, performs incremental sort. The implemented - * algorithm operates in two different modes: - * - Fetching a minimum number of tuples without checking prefix key - * group membership and sorting on all columns when safe. - * - Fetching all tuples for a single prefix key group and sorting on - * solely the unsorted columns. - * We always begin in the first mode, and employ a heuristic to switch - * into the second mode if we believe it's beneficial. - * - * Sorting incrementally can potentially use less memory, avoid fetching - * and sorting all tuples in the the dataset, and begin returning tuples - * before the entire result set is available. - * - * The hybrid mode approach allows us to optimize for both very small - * groups (where the overhead of a new tuplesort is high) and very large - * groups (where we can lower cost by not having to sort on already sorted - * columns), albeit at some extra cost while switching between modes. + * of target sort columns, performs incremental sort. * * Conditions: * -- none. -- 2.17.1