| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Nigel Heron <nheron(at)querymetrics(dot)com>, Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: stats for network traffic WIP |
| Date: | 2013-12-18 09:36:36 |
| Message-ID: | 52B16CA4.5080205@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/12/2013 02:51 AM, Tom Lane wrote:
> The thing that I'm wondering is why the database would be the right place
> to be measuring it at all. If you've got a network usage problem,
> aggregate usage across everything on the server is probably what you
> need to be worried about, and PG can't tell you that.
I suspect this feature would be useful for when you want to try to drill
down and figure out what's having network issues - specifically, to
associate network behaviour with individual queries, individual users,
application_name, etc.
One sometimes faces the same issue with I/O: I know PostgreSQL is doing
lots of I/O, but what exactly is causing the I/O? Especially if you
can't catch it at the time it happens, it can be quite tricky to go from
"there's lots of I/O" to "this query changed from using synchronized
seqscans to doing an index-only scan that's hammering the cache".
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2013-12-18 10:12:49 | Re: Extension Templates S03E11 |
| Previous Message | Sergey Muraviov | 2013-12-18 09:29:37 | Re: Problem with displaying "wide" tables in psql |