Re: [HACKERS] ANALYZE command progress checker
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] ANALYZE command progress checker |
Дата | |
Msg-id | 3451123f-d690-2873-ad4f-7f41b100fac0@openscg.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] ANALYZE command progress checker (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] ANALYZE command progress checker
|
Список | pgsql-hackers |
On 3/6/17 12:49 AM, Michael Paquier wrote: > 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. Well, the ideal scenario is that someone uses the raw data to come up with a good way to just provide ye olde 0-100% progress bar. At that point a single view would do the trick. Perhaps instead of adding more clutter to \dvS we could just have a SRF for now. At over 2800 rows currently, you're not going to notice one more addition to \dfS. -- Jim Nasby, Chief Data Architect, OpenSCG http://OpenSCG.com
В списке pgsql-hackers по дате отправления: