From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | vinayak <Pokale_Vinayak_q3(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ANALYZE command progress checker |
Date: | 2017-03-01 18:20:41 |
Message-ID: | 20170301182041.GD14166@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.?
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
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-03-01 18:25:49 | Re: ANALYZE command progress checker |
Previous Message | Andres Freund | 2017-03-01 18:20:27 | Re: Possible spelling fixes |