Re: Huge number of disk writes after migration to 8.1

Added to TODO:

* Allow statistics collector information to be pulled from the collector
process directly, rather than requiring the collector to write a
filesystem file twice a second?

---------------------------------------------------------------------------

Tom Lane wrote:
> "Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> > In most cases you're going to see extremely few reads compared to writes
> > on pg_stats, right? So why not have the backends connect to the stats
> > process (or perhaps use UDP, or use the pipe, or whatever) and fetch the
> > data when needed. So when nobody fetches any data, there is no overhead
> > (except for the stats process adding up values, of course).
>
> That's a thought. You'd still want the stats file to preserve the data
> across shutdowns, but the update rate could be far slower, maybe once
> every few minutes. The other nice thing is that when you do want the
> stats, you could get current values, not half-a-second-behind values.
>
> > Then you could also push down some filtering to the stats process - for
> > example, when you are reading from pg_stat_activity there is no need to
> > send over the row level stats. IIRC, today you have to read (and write)
> > the whole stats file anyways.
>
> No; the current behavior of grabbing a snapshot of the whole stats
> dataset is a feature, not a bug. It lets you sit there and correlate
> the data using multiple queries, without worrying that the numbers are
> changing under you. We'd lose this ability if the data had to be
> re-fetched for each query because we didn't grab it all.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073