On 2019-Sep-13, Robert Haas wrote: > On Fri, Sep 13, 2019 at 2:49 AM Michael Paquier <mich...@paquier.xyz> wrote: > > On Fri, Sep 06, 2019 at 08:10:58AM -0400, Robert Haas wrote: > > > It's fine if things are updated as well -- it's just you need to make > > > sure that those places know whether or not they are supposed to be > > > doing those updates. Again, why can't we just pass down a value > > > telling them "do reindex-style progress updates" or "do cluster-style > > > progress updates" or "do no progress updates"? > > > > That's invasive. CREATE INDEX reporting goes pretty deep into the > > tree, with steps dedicated to the builds and scans of btree (nbtsort.c > > for example) and hash index AMs.
> Well, if CREATE INDEX progress reporting can't be reasonably done > within the current infrastructure, then it should be reverted for v12 > and not committed again until somebody upgrades the infrastructure. Ummm ... I've been operating --in this thread-- under the assumption that it is REINDEX to blame for this problem, not CREATE INDEX, because my recollection is that I tested CREATE INDEX together with CLUSTER and it worked fine. Has anybody done any actual research that the problem is to blame on CREATE INDEX and not REINDEX? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
