Re: ANALYZE command progress checker

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

In response to

Responses

Browse pgsql-hackers by date

  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