Re: Huge number of disk writes after migration to 8.1
От | Magnus Hagander |
---|---|
Тема | Re: Huge number of disk writes after migration to 8.1 |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE6C7EE9@algol.sollentuna.se обсуждение исходный текст |
Список | pgsql-bugs |
> > 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
В списке pgsql-bugs по дате отправления: