> > 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.
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 -
> > 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.
Oh. Good point. Didn't even know we had that feature, but now that I do
I see it's a good one :-)
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
