On Wed, Dec 18, 2013 at 03:41:24PM -0500, Robert Haas wrote:
> On the other hand, there's not much value in adding monitoring
> features that are going to materially harm performance, and a lot of
> the monitoring features that get proposed die on the vine for exactly
> that reason. I think the ro
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Dec 18, 2013 at 8:47 AM, Stephen Frost wrote:
> > Agreed. My other thought on this is that there's a lot to be said for
> > having everything you need available through one tool- kinda like how
> > Emacs users rarely go outside of it.. :) An
On Wed, Dec 18, 2013 at 8:47 AM, Stephen Frost wrote:
> Agreed. My other thought on this is that there's a lot to be said for
> having everything you need available through one tool- kinda like how
> Emacs users rarely go outside of it.. :) And then there's also the
> consideration that DBAs may
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> 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 probabl
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 te
On 12/11/13 12:51 PM, Tom Lane wrote:
Atri Sharma writes:
On Wed, Dec 11, 2013 at 11:12 PM, Peter Eisentraut wrote:
Is there a reason why you can't get this directly from the OS?
I would say that its more of a convenience to track the usage directly
from the database instead of setting up
I could see this being interesting for FDW plan nodes of the status were
visible in explain. Possibly also time spent waiting on network reads and
writes.
I have a harder time seeing why it's useful to have these stays in
aggregate but I suppose if you had lots of FDW connections or lots of
steami
Atri Sharma writes:
> On Wed, Dec 11, 2013 at 11:12 PM, Peter Eisentraut wrote:
>> Is there a reason why you can't get this directly from the OS?
> I would say that its more of a convenience to track the usage directly
> from the database instead of setting up OS infrastructure to store it.
The
On Wed, Dec 11, 2013 at 11:12 PM, Peter Eisentraut wrote:
> On 12/10/13, 5:08 PM, Tom Lane wrote:
>> Having said that, I can't get very excited about this feature anyway,
>> so I'm fine with rejecting the patch. I'm not sure that enough people
>> care to justify any added overhead at all. The lo
On 12/10/13, 5:08 PM, Tom Lane wrote:
> Having said that, I can't get very excited about this feature anyway,
> so I'm fine with rejecting the patch. I'm not sure that enough people
> care to justify any added overhead at all. The long and the short of
> it is that network traffic generally is wh
Robert Haas writes:
> Yes, I think the overhead of this patch is far, far too high to
> contemplate applying it. It sends a stats collector message after
> *every socket operation*. Once per transaction would likely be too
> much overhead already (think: pgbench -S) but once per socket op is
> i
On Tue, Dec 10, 2013 at 12:29 AM, Fujii Masao wrote:
> On Tue, Dec 10, 2013 at 6:56 AM, Nigel Heron wrote:
>> On Sat, Dec 7, 2013 at 1:17 PM, Fujii Masao wrote:
>>>
>>> Could you share the performance numbers? I'm really concerned about
>>> the performance overhead caused by this patch.
>>>
>>
>
On Tue, Dec 10, 2013 at 10:59 AM, Fujii Masao wrote:
> On Tue, Dec 10, 2013 at 6:56 AM, Nigel Heron wrote:
>> On Sat, Dec 7, 2013 at 1:17 PM, Fujii Masao wrote:
>>>
>>> Could you share the performance numbers? I'm really concerned about
>>> the performance overhead caused by this patch.
>>>
>>
>
On Tue, Dec 10, 2013 at 6:56 AM, Nigel Heron wrote:
> On Sat, Dec 7, 2013 at 1:17 PM, Fujii Masao wrote:
>>
>> Could you share the performance numbers? I'm really concerned about
>> the performance overhead caused by this patch.
>>
>
> I've tried pgbench in select mode with small data sets to avo
On Sat, Dec 7, 2013 at 1:17 PM, Fujii Masao wrote:
>
> Could you share the performance numbers? I'm really concerned about
> the performance overhead caused by this patch.
>
I've tried pgbench in select mode with small data sets to avoid disk
io and didn't see any difference. That was on my old c
Sent from my iPad
> On 07-Dec-2013, at 23:47, Fujii Masao wrote:
>
>> On Wed, Nov 20, 2013 at 3:18 AM, Atri Sharma wrote:
>>> On Tue, Nov 19, 2013 at 11:43 PM, Mike Blackwell
>>> wrote:
>>> This patch looks good to me. It applies, builds, and runs the regression
>>> tests. Documentation i
On Wed, Nov 20, 2013 at 3:18 AM, Atri Sharma wrote:
> On Tue, Nov 19, 2013 at 11:43 PM, Mike Blackwell
> wrote:
>> This patch looks good to me. It applies, builds, and runs the regression
>> tests. Documentation is included and it seems to do what it says. I don't
>> consider myself a code ex
On Tue, Nov 19, 2013 at 11:43 PM, Mike Blackwell wrote:
> This patch looks good to me. It applies, builds, and runs the regression
> tests. Documentation is included and it seems to do what it says. I don't
> consider myself a code expert, but as far as I can see it looks fine. This
> is a pre
This patch looks good to me. It applies, builds, and runs the regression
tests. Documentation is included and it seems to do what it says. I don't
consider myself a code expert, but as far as I can see it looks fine. This
is a pretty straightforward enhancement to the existing pg_stat_* code.
On Fri, 2013-11-08 at 10:01 -0500, Nigel Heron wrote:
> here's v4 of the patch. I added documentation and a new global view
> called "pg_stat_socket" (includes bytes_sent, bytes_received and
> stats_reset time)
Your patch needs to be rebased:
CONFLICT (content): Merge conflict in src/test/regress
On Thu, Nov 7, 2013 at 8:21 PM, Greg Stark wrote:
>
>
> The most interesting thing that I could see calculating from these stats
> would require also knowing how much time was spent waiting on writes and
> reads on the network. With the cumulative time spent as well as the count of
> syscalls you
Also still to be tested: performance impact.
__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management | RR Donnelley*
1750 Wallace Ave | St Charles, IL 60174-3401
Office: 630.313.7818
mike.black
Patch applies and builds against git HEAD (as of 6790e738031089d5). "make
check" runs cleanly as well.
The new features appear to work as advertised as far as I've been able to
check.
The code looks good as far as I can see. Documentation patches are
included for the new features.
Still to be
On Tue, Oct 29, 2013 at 11:26 AM, Nigel Heron wrote:
>>
>> So, for now, the counters only track sockets created from an inbound
>> (client to server) connection.
>
> here's v3 of the patch (rebase and cleanup).
>
Hi,
here's v4 of the patch. I added documentation and a new global view
called "pg_s
On Mon, Oct 21, 2013 at 5:14 AM, Nigel Heron wrote:
> - can be used to find misbehaving connections.
> - can be used in multi-user/multi-database clusters for resource usage
> tracking.
> - competing databases have such metrics.
The most interesting thing that I could see calculating from these
>
> So, for now, the counters only track sockets created from an inbound
> (client to server) connection.
here's v3 of the patch (rebase and cleanup).
-nigel.
*** a/src/backend/catalog/system_views.sql
--- b/src/backend/catalog/system_views.sql
***
*** 586,592 CREATE VIEW pg_stat
On Wed, Oct 23, 2013 at 2:44 PM, Nigel Heron wrote:
> Hi, thanks, I'm still actively working on this patch. I've gotten the
> traffic counters working when using SSL enabled clients (includes the
> ssl overhead now) but I still have the walsender transfers under SSL
> to work on.
> I'll post an up
On Wed, Oct 23, 2013 at 2:10 PM, Atri Sharma wrote:
>
> Adding myself as the co reviewer specifically for the testing
> purposes, if its ok with you.
>
It's perfectly fine with me. Please do!
__
*Mike Blackw
On Thu, Oct 24, 2013 at 12:30 AM, Mike Blackwell wrote:
>
> On Wed, Oct 23, 2013 at 1:58 PM, Atri Sharma wrote:
>
>>
>> IMO, the idea is pretty good. Its just that we need to do some wide
>> spectrum performance testing. Thats only my thought though.
>
>
>
> I'm looking at trying to do some perfo
On Wed, Oct 23, 2013 at 2:58 PM, Atri Sharma wrote:
> On Thu, Oct 24, 2013 at 12:23 AM, Mike Blackwell
> wrote:
>> Sounds good. I personally don't have any interest in log file i/o counters,
>> but that's just me. I wonder if stats collector counters might be useful...
>> I seem to recall an e
On Wed, Oct 23, 2013 at 1:58 PM, Atri Sharma wrote:
>
> IMO, the idea is pretty good. Its just that we need to do some wide
> spectrum performance testing. Thats only my thought though.
I'm looking at trying to do some performance testing on this. Any
suggestions on test scenarios, etc?
_
On Thu, Oct 24, 2013 at 12:23 AM, Mike Blackwell wrote:
> Sounds good. I personally don't have any interest in log file i/o counters,
> but that's just me. I wonder if stats collector counters might be useful...
> I seem to recall an effort to improve that area. Maybe not enough use to
> take t
Sounds good. I personally don't have any interest in log file i/o
counters, but that's just me. I wonder if stats collector counters might
be useful... I seem to recall an effort to improve that area. Maybe not
enough use to take the performance hit on a regular basis, though.
_
Hi, thanks, I'm still actively working on this patch. I've gotten the
traffic counters working when using SSL enabled clients (includes the
ssl overhead now) but I still have the walsender transfers under SSL
to work on.
I'll post an updated patch when i have it figured out.
Since the patch changes
I added this to the current CF, and am starting to review it as I have time.
__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management | RR Donnelley*
1750 Wallace Ave | St Charles, IL 60174-3401
Nigel,
* Nigel Heron (nhe...@querymetrics.com) wrote:
> Hi, I've been using postgres for many years but never took the time to play
> with the code until now. As a learning experience i came up with this WIP
> patch to keep track of the # of bytes sent and received by the server over
> it's commun
Hi, I've been using postgres for many years but never took the time to play
with the code until now. As a learning experience i came up with this WIP
patch to keep track of the # of bytes sent and received by the server over
it's communication sockets. Counters are kept per database, per connection
37 matches
Mail list logo
