Skip site navigation (1) Skip section navigation (2)

Re: statistics buffer is full

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Jeff Frost <jeff(at)frostconsultingllc(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: statistics buffer is full
Date: 2006-11-09 12:14:48
Message-ID: 20061109121448.GS14845@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-admin
Jeff Frost wrote:
> On Wed, 8 Nov 2006, Joshua D. Drake wrote:
> 
> >>hah!  Does that mean it's just the buffering for pg_stat_activity and not 
> >>for
> >>planner statistics?  That doesn't make me feel too bad in this case.
> >
> >Yeah it is nothing to worry about, however turning it off is certainly a
> >performance benefit.
> >
> 
> So, then the next question: is that error because the command string was 
> too long or because there were too many command strings in the buffer at 
> once (i.e. it got backed up a bit and filled)?

Yeah, it got backed up.  It's an UDP socket and it's having trouble
keeping up.  Disabling stats_command_string removes the higher producer
of "statistics" traffic, and the price you pay for it is that queries
don't show up in pg_stat_activity.  You can still see the tags in ps
though, and of course you'll have them in the log if you enabled that.

> It would be a drag to be without pg_stat_activity on this system.  The 
> performance detriment is lessened in 8.2, correct?

Yes, by not using the UDP socket to transmit the command string in the
first place.  They are now just stored in memory, which is considerably
faster.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

pgsql-admin by date

Next:From: Jerry SieversDate: 2006-11-09 13:46:42
Subject: Re: Manual sys catalog constraint setup to avoid downtime?
Previous:From: Paolo NegriDate: 2006-11-09 10:26:31
Subject: Re: pg_dump and foreign keys troubles

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group