On 2019-Apr-05, Peter Eisentraut wrote:
> It seems we can easily extend this to also monitor REINDEX
> [CONCURRENTLY]. Attached is a quick patch.
That's much easier than I was expecting. I think we should endeavor to
get this done for pg12.
> For the concurrently part, we currently don't have any phases defined
> for the index swap and drop, but maybe we can just skip that initially.
> What happens if we don't have those?
Users are going to wonder why the other phases don't appear to complete
for a long time :-) Keep in mind that the "waiting" phases are very
confusing to users. I suggest we just define additional phase numbers
for those phases, then switch the "false" argument to
WaitForLockersMultiple to "true", and it should work :-) Doc-wise, list
all the phases in the same docbook table, indicate that REINDEX is also
covered, and document in an easier-to-follow fashion which phases each
command goes through.
> It might be nice to have a column in the view not only for the table OID
> but also the index OID. That is obviously not so useful for CREATE
> INDEX but more useful for REINDEX. I haven't looked into how adding
> that would work.
Yeah, I think that's simple enough -- the CLUSTER one already does that,
I think. Another thing for REINDEX TABLE is that we should add a count
of indexes to process, and how many are done.
I was wondering about reporting the command being run. In the progress_cluster
view we have a "command" column, which says either CLUSTER or VACUUM FULL.
I didn't add one for CREATE INDEX vs. CONCURRENTLY because it seemed to
me that joining to pg_stat_activity ought to be sufficient. If we agree
with that reasoning, then we should remove the column from the CLUSTER
view, I think. If not, we should add one to the create_index view.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services