On Fri, Sep 6, 2019 at 1:44 AM Michael Paquier <michael@paquier.xyz> wrote:
> One idea I got was to pass the command ID as an extra argument of the
> update routine. I am not completely sure either if we need this level
> of complication.
I still don't think that's the right approach.
> > Those are just weaknesses of the infrastructure. Perhaps there is a
> > better solution, but there's no intrinsic reason that we can't avoid
> > them by careful coding.
>
> Perhaps. The current infra allows the addition of a progress report
> in code paths which are isolated from other things. For CLUSTER, most
> things are fine as long as the progress is updated in cluster_rel(),
> the rest is too internal.
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"?
> > Well, it might be OK to do that if we're clear that this is the index
> > progress-reporting view and the command is CLUSTER but it happens to
> > be building an index now so we're showing it here. But I don't see
> > how it would work anyway: you can't reported cascading progress
> > reports in shared memory because you've only got a fixed amount of
> > space.
>
> I don't see exactly why we could not switch to a fixed number of
> slots, say 8, with one code path to start a progress which adds an
> extra report on the stack, one to remove one entry from the stack, and
> a new one to reset the whole thing for a backend. This would not need
> much restructuration of course.
You could do that, but I don't think it's probably that great of an
idea. Now you've built something which is significantly more complex
than the original design of this feature, but still not good enough to
report on the progress of a query tree. I tend to think we should
confine ourselves to the progress reporting that can reasonably be
done within the current infrastructure until somebody invents a really
general mechanism that can handle, essentially, an EXPLAIN-on-the-fly
of a current query tree.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company