Re: Huge number of disk writes after migration to 8.1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
Cc: "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-01-19 14:58:38
Message-ID: 15481.1137682718@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Huxton 2006-01-19 16:00:57 Re: Execution of stored procedures
Previous Message Alvaro Herrera 2006-01-19 13:51:18 Re: Huge number of disk writes after migration to 8.1