Re: Background Processes and reporting
От | Kevin Grittner |
---|---|
Тема | Re: Background Processes and reporting |
Дата | |
Msg-id | CACjxUsMwha4eWqiAfOpMXDRKMQftFi+=cY7P5v57cEsS94bF4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Background Processes and reporting (Vladimir Borodin <root@simply.name>) |
Список | pgsql-hackers |
On Sat, Mar 12, 2016 at 11:40 AM, Vladimir Borodin <root@simply.name> wrote: > 12 марта 2016 г., в 13:59, Amit Kapila <amit.kapila16@gmail.com> написал(а): >> I think here another point which needs more thoughts is that many of the >> pg_stat_activity fields are not relevant for background processes, ofcourse >> one can say that we can keep those fields as NULL, but still I think that >> indicates it is not the most suitable way to expose such information. >> >> Another way could be to have new view like pg_stat_background_activity with >> only relevant fields or try expose via individual views like >> pg_stat_bgwriter. > > From the DBA point of view it is much more convenient to see all wait events > in one view. I don’t know if it is right to break compability even more, but > IMHO exposing this data in different views is a bad plan. +1 If they are split into separate views I think that there will be a lot of effort put into views to present the UNION of them, probably with weird corner cases and race conditions. A single view can probably better manage race conditions, and a WHERE clause is not as tricky for the DBA and/or end user. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: