Re: [HACKERS] ANALYZE command progress checker - Mailing list pgsql-hackers

On 2017-03-03 15:33:15 -0500, David Steele wrote:
> 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'm not following. As I pointed out, we already have this framework?
This patch is just a short one using that framework?


> I propose we move this to the 2017-07 CF so the idea can be more fully
> developed.

I don't see that being warranted in this case, we're really not talking
about something complicated:doc/src/sgml/monitoring.sgml         |  135
+++++++++++++++++++++++++++++++++++src/backend/catalog/system_views.sql|   16 ++++src/backend/commands/analyze.c
|  34 ++++++++src/backend/utils/adt/pgstatfuncs.c  |    2 src/include/commands/progress.h      |   13
+++src/include/pgstat.h                |    3 src/test/regress/expected/rules.out  |   18 ++++7 files changed, 219
insertions(+),2 deletions(-)
 
excepting tests and docs, this is very little actual code.

Greetings,

Andres Freund