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

From David Fetter
Subject Re: monitoring CREATE INDEX [CONCURRENTLY]
Date
Msg-id 20190310174324.GA26948@fetter.org
Whole thread Raw
In response to Re: monitoring CREATE INDEX [CONCURRENTLY]  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: monitoring CREATE INDEX [CONCURRENTLY]
List pgsql-hackers
On Mon, Mar 04, 2019 at 05:46:07PM -0300, Alvaro Herrera wrote:
> 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.

Would it be a very large lift to report progress for the rest of the
index types we support?

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Next
From: Andrew Dunstan
Date:
Subject: Re: subscriptionCheck failures on nightjar