Re: Background Processes and reporting

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Background Processes and reporting
Дата
Msg-id 20160314200200.x7zvnexx2apgxzhb@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Background Processes and reporting  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Background Processes and reporting  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On 2016-03-12 16:29:11 +0530, Amit Kapila wrote:
> On Sat, Mar 12, 2016 at 3:10 AM, Andres Freund <andres@anarazel.de> wrote:
> >
> >
> > > Similarly for the wait event stuff - checkpointer, wal writer,
> > > background writer are in many cases processes that very often are
> > > blocked on locks, IO and such.  Thus restricting the facility to
> > > database connected processes seems like a loss.
> >
> > I think one way to address this would be to not only report
> > PgBackendStatus type processes in pg_stat_activity. While that'd
> > obviously be a compatibility break, I think it'd be an improvement.
> >
> 
> 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.

But neither are all of them relevant for autovacuum workers, and we
already show them.  pg_stat_activity as a name imo doesn't really imply
that it's about plain queries.  ISTM we should add a 'backend_type'
column that is one of backend|checkpointer|autovacuum|autovacuum-worker|wal writer| bgwriter| bgworker
(or similar). That makes querying easier.  And then display all shmem
connected processes.

> 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.

I think the second is a pretty bad alternative; it'll force us to add
new views with very similar information; and it'll be hard to get
information about the whole system.   I mean if you want to know which
locks are causing problems, you don't primarily care whether it's a
background process or a backend that has contention issues.


> Do you intend to get this done for 9.6 considering an add-on patch for wait
> event information displayed in pg_stat_activity?

I think we should fix this for 9.6; it's a weakness in a new
interface. Let's not yank people around more than we need to.

I'm willing to do some work on that, if we can agree upon a course.

Andres



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Paul Ramsey
Дата:
Сообщение: Re: Parallel Aggregate
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: Upper planner pathification