Chris <lists@xxxxxxxxxx> writes: > After the file was made larger and I stopped the vacuum process, I started > seeing the problem. All other postgress processes were quiet, but the stats > collector was constantly causing anywhere from 20-60 of the IO on the server. > Since all the other postgres processes weren't really doing anything, and it is > a busy web server which is predominately MySQL, I'm fairly curious as to what > it is doing. Yeah, the stats collector rewrites the stats file every half second, if there have been any changes since last time --- so the bigger the file, the more overhead. (8.4 is smarter about this, but that doesn't help you on 8.3.) > I straced the stats collector process. I wasn't sure what else to trace as > there wasn't a single other postgres process doing anything. That strace doesn't really prove much; it's what I'd expect. Here's what to do: start a PG session, and strace that session's backend *and* the stats collector while you manually do VACUUM some-small-table. The VACUUM command should try to send some messages to the stats collector process. I'm wondering if those get dropped somehow. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
