| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Ilya Kosmodemiansky <ik(at)postgresql-consulting(dot)com> |
| Subject: | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
| Date: | 2015-06-22 22:23:48 |
| Message-ID: | 55888AF4.5070502@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6/22/15 12:37 PM, Robert Haas wrote:
> It's
> not my goal here to create some kind of a performance counter system,
> even though that would be valuable and could possibly be based on the
> same infrastructure, but rather just to create a very simple system
> that lets people know, without any developer tools, what is causing a
> backend that has accepted a query and not yet returned a result to be
> off-CPU rather than on-CPU.
Ilya Kosmodemiansky presented such a system at pgCon[1], and hopes to
submit an initial patch in the coming weeks. The general idea was to do
something similar to what you're describing (though, I believe even more
granular) and have a bgworker accumulating that information.
[1] http://www.pgcon.org/2015/schedule/events/809.en.html
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2015-06-22 23:06:06 | Re: [Proposal] Progress bar for pg_dump/pg_restore |
| Previous Message | Tom Lane | 2015-06-22 21:31:05 | Re: NULL passed as an argument to memcmp() in parse_func.c |