| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | David Steele <david(at)pgmasters(dot)net> |
| Cc: | vinayak <Pokale_Vinayak_q3(at)lab(dot)ntt(dot)co(dot)jp>, 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-06 06:49:23 |
| Message-ID: | CAB7nPqS=+fP2HGN=SWT3=4_A6etzVmvb412o1P7DiwtaWJrYug@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Mar 4, 2017 at 5:33 AM, David Steele <david(at)pgmasters(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kuntal Ghosh | 2017-03-06 06:56:24 | Re: Performance degradation in TPC-H Q18 |
| Previous Message | Kyotaro HORIGUCHI | 2017-03-06 06:44:52 | Re: [BUG FIX] Removing NamedLWLockTrancheArray |