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. [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c16dc1aca5e -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers