Re: Background Processes and reporting - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Background Processes and reporting
Date
Msg-id CACjxUsMwha4eWqiAfOpMXDRKMQftFi+=cY7P5v57cEsS94bF4A@mail.gmail.com
Whole thread Raw
In response to Re: Background Processes and reporting  (Vladimir Borodin <root@simply.name>)
List 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 by date:

Previous
From: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Subject: [PATCH] Use correct types and limits for PL/Perl SPI query results
Next
From: David Steele
Date:
Subject: Re: Password identifiers, protocol aging and SCRAM protocol