> > In most cases you're going to see extremely few reads compared to=20
> > writes on pg_stats, right? So why not have the backends=20
> connect to the=20
> > stats process (or perhaps use UDP, or use the pipe, or=20
> whatever) and=20
> > fetch the data when needed. So when nobody fetches any=20
> data, there is=20
> > no overhead (except for the stats process adding up values,=20
> of course).
>=20
> That's a thought. You'd still want the stats file to=20
> preserve the data across shutdowns, but the update rate could=20
> be far slower, maybe once every few minutes. The other nice=20
> thing is that when you do want the stats, you could get=20
> current values, not half-a-second-behind values.
Exactly. For those who care a lot about their stats data, we could offer
a config parameter for how often to write out the stats file.
> > Then you could also push down some filtering to the stats process -=20
> > for example, when you are reading from pg_stat_activity there is no=20
> > need to send over the row level stats. IIRC, today you have to read=20
> > (and write) the whole stats file anyways.
>=20
> No; the current behavior of grabbing a snapshot of the whole=20
> stats dataset is a feature, not a bug. It lets you sit there=20
> and correlate the data using multiple queries, without=20
> worrying that the numbers are changing under you. We'd lose=20
> this ability if the data had to be re-fetched for each query=20
> because we didn't grab it all.
Oh. Good point. Didn't even know we had that feature, but now that I do
I see it's a good one :-)
//Magnus
