Re: [HACKERS] ANALYZE command progress checker
От | David Steele |
---|---|
Тема | Re: [HACKERS] ANALYZE command progress checker |
Дата | |
Msg-id | d1cb0d6c-8bc3-af99-98a8-ef8e84b646aa@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] ANALYZE command progress checker (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] ANALYZE command progress checker
Re: [HACKERS] ANALYZE command progress checker |
Список | pgsql-hackers |
On 3/1/17 1:25 PM, Andres Freund wrote: > On 2017-03-01 10:20:41 -0800, David Fetter wrote: >> On Wed, Mar 01, 2017 at 09:45:40AM -0500, Peter Eisentraut wrote: >>> On 2/28/17 04:24, vinayak wrote: >>>> The view provides the information of analyze command progress details as >>>> follows >>>> postgres=# \d pg_stat_progress_analyze >>>> View "pg_catalog.pg_stat_progress_analyze" >>> >>> Hmm, do we want a separate "progress" system view for every kind of >>> command? What if someone comes up with a progress checker for CREATE >>> INDEX, REINDEX, CLUSTER, etc.? > > I don't think that'd be that bad, otherwise the naming of the fields is > complicated. I guess the alternative (or do both?) would be to to have > a pivoted table, but that'd painful to query. Do you have a better idea? > > >> Some kind of design for progress seems like a good plan. Some ideas: >> >> - System view(s) >> >> This has the advantage of being shown to work at least to a PoC by >> this patch, and is similar to extant system views like >> pg_stat_activity in the sense of capturing a moment in time. >> >> - NOTIFY >> >> Event-driven model as opposed to a polling one. This is >> attractive on efficiency grounds, less so on reliability ones. >> >> - Something added to the wire protocol >> >> More specialized, limits the information to the session where the >> command was issued >> >> - Other things not named here > > We now have a framework for this [1] (currently used by vacuum, but > extensible). The question is about presentation. I'm fairly sure that > we shouldn't just add yet another framework, and I doubt that that's > what's proposed by Peter. I think the idea of a general progress view is very valuable and there are a ton of operations it could be used for: full table scans, index rebuilds, vacuum, copy, etc. However, I feel that this proposal is not flexible enough and comes too late in the release cycle to allow development into something that could be committed. I propose we move this to the 2017-07 CF so the idea can be more fully developed. -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: