diff options
| author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2021-06-11 19:07:32 -0400 |
|---|---|---|
| committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2021-06-11 19:07:32 -0400 |
| commit | 065ce069ae4fe5f59251435ebfe13e14a2d5874c (patch) | |
| tree | c0bf93446ef0d0d981e096d68cb3075efb16fd3a /src | |
| parent | b270713fd44b1378cebc3177e092add0155b55b6 (diff) | |
| download | postgresql-065ce069ae4fe5f59251435ebfe13e14a2d5874c.tar.gz postgresql-065ce069ae4fe5f59251435ebfe13e14a2d5874c.zip | |
Report sort phase progress in parallel btree build
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
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/access/nbtree/nbtsort.c | 17 |
1 files changed, 10 insertions, 7 deletions
diff --git a/src/backend/access/nbtree/nbtsort.c b/src/backend/access/nbtree/nbtsort.c index 408cfafd5a7..bde61b7c5f0 100644 --- a/src/backend/access/nbtree/nbtsort.c +++ b/src/backend/access/nbtree/nbtsort.c @@ -548,6 +548,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); @@ -1971,16 +1972,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 |