Re: monitoring CREATE INDEX [CONCURRENTLY] - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: monitoring CREATE INDEX [CONCURRENTLY]
Date
Msg-id 20190304204607.GA15946@alvherre.pgsql
Whole thread Raw
In response to Re: monitoring CREATE INDEX [CONCURRENTLY]  (Rahila <rahila.syed@2ndquadrant.com>)
Responses Re: monitoring CREATE INDEX [CONCURRENTLY]
Re: monitoring CREATE INDEX [CONCURRENTLY]
List pgsql-hackers
Hi Rahila,

Thanks for looking.

On 2019-Mar-04, Rahila wrote:

> 1. Thank you for incorporating review comments.
> Can you please rebase the latest 0001-Report-progress-of-
> CREATE-INDEX-operations.patch on master? Currently it does not apply on
> 754b90f657bd54b482524b73726dae4a9165031c

Hmm, rebased to current master.  Didn't conflict at all when rebasing,
so it's strange that it didn't apply.

> >   15:56:44.694 | building index (3 of 8): initializing (1/5)            |       442478 |      442399 |            0
|          0 |                0 |               0
 
> >   15:56:44.705 | building index (3 of 8): sorting tuples, spool 1 (3/5) |       442478 |      442399 |    100000000
|          0 |                0 |               0
 
> >   15:56:44.716 | building index (3 of 8): sorting tuples, spool 1 (3/5) |       442478 |      442399 |    100000000
|          0 |                0 |               0
 
> >   15:56:44.727 | building index (3 of 8): final btree sort & load (5/5) |       442478 |      442399 |    100000000
|      79057 |                0 |               0
 
> >   15:56:44.738 | building index (3 of 8): final btree sort & load (5/5) |       442478 |      442399 |    100000000
|     217018 |                0 |               0
 
> >   15:56:44.75  | building index (3 of 8): final btree sort & load (5/5) |       442478 |      442399 |    100000000
|     353804 |                0 |               0
 
> 2. In the above report, even though we are reporting progress in terms of
> tuples_done for final btree sort & load phase we have not cleared
> the blocks_done entry from previous phases. I think this can be confusing as
> the blocks_done does not correspond to the tuples_done in the final btree
> sort & load phase.

Good point.  Done in the attached version, wherein I also added comments
to explain the IndexBuildHeapScan API change.  I didn't change the hash
AM implementation here.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Next
From: Tom Lane
Date:
Subject: Re: Rare SSL failures on eelpout