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

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.
>     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:

Reply via email to