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

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 (view raw or flat)
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

pgsql-bugs by date

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

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