Re: [HACKERS] ANALYZE command progress checker - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] ANALYZE command progress checker
Date
Msg-id CAB7nPqS=+fP2HGN=SWT3=4_A6etzVmvb412o1P7DiwtaWJrYug@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] ANALYZE command progress checker  (David Steele <david@pgmasters.net>)
Responses Re: [HACKERS] ANALYZE command progress checker  (Jim Nasby <jim.nasby@openscg.com>)
List pgsql-hackers
On Sat, Mar 4, 2017 at 5:33 AM, David Steele <david@pgmasters.net> wrote:
> 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.

Well, each command really has its own requirements in terms of data to
store, so we either finish with a bunch of small tables that anyone
could query and join as they wish or a somewhat unique table that is
bloated with all the information, with a set of views on top of it to
query all the information. For extensibility's sake of each command
(for example imagine that REINDEX could be extended with a
CONCURRENTLY option and multiple phases), I would think that having a
table per command type would not be that bad.
-- 
Michael



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] [BUG FIX] Removing NamedLWLockTrancheArray
Next
From: Kuntal Ghosh
Date:
Subject: Re: [HACKERS] Performance degradation in TPC-H Q18