Re: [HACKERS] ANALYZE command progress checker
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] ANALYZE command progress checker |
Дата | |
Msg-id | 968b4eda-2417-8b7b-d468-71643cf088b6@openscg.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] ANALYZE command progress checker (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] ANALYZE command progress checker
|
Список | pgsql-hackers |
On 3/10/17 1:06 PM, Andres Freund wrote: > Hi, > > On 2017-03-10 02:11:18 -0600, Jim Nasby wrote: >> Perhaps instead of adding more clutter to \dvS we could just have a SRF for >> now. > > I don't see that as clutter, it's useful information, and keeping it > discoverable is good, not bad. If we keep adding status reporting commands at some point it's going to get unwieldy. Though, if they were in their own schema... >> At over 2800 rows currently, you're not going to notice one more >> addition to \dfS. > > I think it's hard to design a good SRF for this. Because the fields for > different types of progress are different / empty, you can't just > trivially return them as rows. You'd have to do some EAV like > 'command, field_name1, field_value1, ...' type of thing - not > particularly pretty / easy to use. Oh, I wasn't suggesting a single SRF for everything. Hopefully users will eventually figure out a good formula to drive a "progress bar" for each type of monitor, which is what you really want anyway (at least 99% of the time). If we got there we could have a single view that gave the % complete for every command that was providing feedback. If someone wanted details they could hit the individual SRF. -- Jim Nasby, Chief Data Architect, OpenSCG http://OpenSCG.com
В списке pgsql-hackers по дате отправления: