|From:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|To:||Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Thomas Reiss <thomas(dot)reiss(at)dalibo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: RFC: replace pg_stat_activity.waiting with something more descriptive|
|Views:||Raw Message | Whole Thread | Download mbox|
On Thu, Mar 24, 2016 at 7:28 AM, Alexander Korotkov
> Since, patch for exposing current wait event information in PGPROC was
> committed, it becomes possible to collect wait event statistics using
> sampling. Despite I'm not fan of this approach, it is still useful and
> definitely better than nothing.
> In PostgresPro, we actually already had it. Now, it's too late to include
> something new to 9.6. This is why I've rework it and publish at github as
> an extension for 9.6: https://github.com/postgrespro/pg_wait_sampling/
> Hopefully, it could be considered as contrib for 9.7.
Spiffy. That was fast.
I think the sampling approach is going to be best on very large
systems under heavy load; I suspect counting every event is going to
be too expensive - especially once we add more events for things like
block read and client wait. It is quite possible that we can do other
things when tracing individual sessions or in scenarios where some
performance degradation is OK. But I like the idea of doing the
sampling thing first - I think that will be very useful.
The Enterprise PostgreSQL Company
|Next Message||Tom Lane||2016-03-24 14:31:57||Re: PostgreSQL 9.6 behavior change with set returning (funct).*|
|Previous Message||Stas Kelvich||2016-03-24 14:20:14||Re: 2PC support for pglogical|