Re: monitoring CREATE INDEX [CONCURRENTLY]
От | Alvaro Herrera |
---|---|
Тема | Re: monitoring CREATE INDEX [CONCURRENTLY] |
Дата | |
Msg-id | 20190222215423.GA16912@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: monitoring CREATE INDEX [CONCURRENTLY] (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: monitoring CREATE INDEX [CONCURRENTLY]
|
Список | pgsql-hackers |
On 2019-Feb-13, Amit Langote wrote: > Doesn't the name amphasename sound a bit too generic, given that it can > only describe the phases of ambuild? Maybe ambuildphase? Hmm, yeah, maybe it does. I renamed it "ambuildphasename", since it's not about reporting the phase itself -- it's about translating the phase number to the string that's reported to the user. The attached patch does it that way. Also, when an index build uses an AM that doesn't support progress reporting, it no longer reports a NULL phase name while building. I also changed it to report the progress of phase 7 (heap scan validation) using block numbers rather than tuple counts. I also tweaked the strings reported in the view. They're clearer now IMO. One slight annoyance is that when parallel workers are used, the last block number reported in phase 3/subphase 2 (IndexBuildHeapScan stuff) is not necessarily accurate, since the tail of the table could well be scanned by a worker that's not the leader, and we only report in the leader when it gets a new block. When the AM does not support progress reporting, everything stays as zeros during the index build phase. It's easy to notice how slow hash indexes are to build compared to btrees this way! Maybe it'd be better fallback on reporting block numbers in IndexBuildHeapScan when this happens. Thoughts? I added docs to the monitoring section -- that's the bulkiest part of the patch. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: