Re: [HACKERS] ANALYZE command progress checker

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] ANALYZE command progress checker
Дата
Msg-id CAB7nPqS=+fP2HGN=SWT3=4_A6etzVmvb412o1P7DiwtaWJrYug@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] ANALYZE command progress checker  (David Steele <david@pgmasters.net>)
Ответы Re: [HACKERS] ANALYZE command progress checker
Список 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 по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] [BUG FIX] Removing NamedLWLockTrancheArray
Следующее
От: Kuntal Ghosh
Дата:
Сообщение: Re: [HACKERS] Performance degradation in TPC-H Q18