Report sort phase progress in parallel btree build
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Fri, 11 Jun 2021 23:07:32 +0000 (19:07 -0400)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Fri, 11 Jun 2021 23:07:32 +0000 (19:07 -0400)
We were already reporting it, but only after the parallel workers were
finished, which is visibly much later than what happens in a serial
build.

With this change we report it when the leader starts its own sort phase
when participating in the build (the normal case).  Now this might
happen a little later than when the workers start their sorting phases,
but a) communicating the actual phase start from workers is likely to be
a hassle, and b) the sort phase start is pretty fuzzy anyway, since
sorting per se is actually initiated by tuplesort.c internally earlier
than tuplesort_performsort() is called.

Backpatch to pg12, where the progress reporting code for CREATE INDEX
went in.

Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com>
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>
Reviewed-by: Greg Nancarrow <gregn4422@gmail.com>
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/1128176d-1eee-55d4-37ca-e63644422adb

src/backend/access/nbtree/nbtsort.c

index 286d2cc93f197daf2e850a3deee7f41bfb4a6e42..d177b9f233811b72e0e588688d1c1e6a21f34640 100644 (file)
@@ -562,6 +562,7 @@ _bt_leafbuild(BTSpool *btspool, BTSpool *btspool2)
    }
 #endif                         /* BTREE_BUILD_STATS */
 
+   /* Execute the sort */
    pgstat_progress_update_param(PROGRESS_CREATEIDX_SUBPHASE,
                                 PROGRESS_BTREE_PHASE_PERFORMSORT_1);
    tuplesort_performsort(btspool->sortstate);
@@ -1833,16 +1834,18 @@ _bt_parallel_scan_and_sort(BTSpool *btspool, BTSpool *btspool2,
                                       true, progress, _bt_build_callback,
                                       (void *) &buildstate, scan);
 
-   /*
-    * Execute this worker's part of the sort.
-    *
-    * Unlike leader and serial cases, we cannot avoid calling
-    * tuplesort_performsort() for spool2 if it ends up containing no dead
-    * tuples (this is disallowed for workers by tuplesort).
-    */
+   /* Execute this worker's part of the sort */
+   if (progress)
+       pgstat_progress_update_param(PROGRESS_CREATEIDX_SUBPHASE,
+                                    PROGRESS_BTREE_PHASE_PERFORMSORT_1);
    tuplesort_performsort(btspool->sortstate);
    if (btspool2)
+   {
+       if (progress)
+           pgstat_progress_update_param(PROGRESS_CREATEIDX_SUBPHASE,
+                                        PROGRESS_BTREE_PHASE_PERFORMSORT_2);
        tuplesort_performsort(btspool2->sortstate);
+   }
 
    /*
     * Done.  Record ambuild statistics, and whether we encountered a broken