From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | vinayak <Pokale_Vinayak_q3(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, David Fetter <david(at)fetter(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ANALYZE command progress checker |
Date: | 2017-03-03 20:33:15 |
Message-ID: | d1cb0d6c-8bc3-af99-98a8-ef8e84b646aa@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 propose we move this to the 2017-07 CF so the idea can be more fully
developed.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2017-03-03 20:49:38 | Re: SQL/JSON in PostgreSQL |
Previous Message | Peter Eisentraut | 2017-03-03 20:04:32 | Re: Unhelpful typesetting of callouts in example queries in the docs |