Re: monitoring CREATE INDEX [CONCURRENTLY]
От | Robert Haas |
---|---|
Тема | Re: monitoring CREATE INDEX [CONCURRENTLY] |
Дата | |
Msg-id | CA+TgmoZiHr2MMJy+s4=EsmrFhtQk93e14MjaLebAhC92CLZjgQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: monitoring CREATE INDEX [CONCURRENTLY] (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: monitoring CREATE INDEX [CONCURRENTLY]
|
Список | pgsql-hackers |
On Thu, Mar 28, 2019 at 12:07 PM Simon Riggs <simon@2ndquadrant.com> wrote: > Seems more like our own labelling of the phases is responsible for that, rather than it being a specific problem. The numberingshould reflect the ordinal executed step number. So if a VACUUM has required two sets of index scanning, the heapscan phase (normally phase 3) should be labelled phase 6 when it occurs the second time, rather than "phase 3 again,doh" which clearly doesn't work. That would not be too simple to do with the infrastructure we have available, I think. Also, Alvaro's showed phase names like '3 of 8', but if you regarded each set of index scans as a separate phase rather than a repetition of a phase that had already happened, you wouldn't know whether there were going to be 8 phases in total or some other number, because you don't know how many times you're going to scan the indexes. I suggest that it makes sense to leave the phase numbers out of this commit. If someone wants to make a proposal for adding phase numbers to the various commands that now support progress reporting as a separate commit, then that can be discussed separately. BTW, if we are going to do that, it might be best to put then in separate view columns rather than making them part of the phase names. Somebody might want to look for those phase names using SQL or client-side logic and not have the logic get broken if we renumber the phases. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: