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
