Re: Huge number of disk writes after migration to 8.1

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Huge number of disk writes after migration to 8.1
Date: 2006-02-01 17:32:39
Message-ID: 200602011732.k11HWdQ00507@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Grossman 2006-02-01 20:29:05 PostgreSQL Windows
Previous Message Tom Lane 2006-02-01 17:19:55 Re: Bug in query planer ?