Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter
От | Greg Smith |
---|---|
Тема | Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter |
Дата | |
Msg-id | 4F1C9854.7000908@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter (Jeff Janes <jeff.janes@gmail.com>) |
Список | pgsql-hackers |
Jeff Janes wrote: > I'm finding the backend_writes column pretty unfortunate. The only > use I know of for it is to determine if the bgwriter is lagging > behind. Yet it doesn't serve even this purpose because it lumps > together the backend writes due to lagging background writes, and the > backend writes "by design" due to the use buffer access strategy > during bulk inserts. > > If I'm running a tightly controlled benchmark on an otherwise unused > server and I know that no BAS is being used, then I can meaningfully > use backend_writes. That is a pretty limiting limit. > I don't think it's quite that bad in general; this presumes a moderate amount of BAS writes relative to other activity. But I understand your concern better now. I don't think the sorts of workloads you seem to have a lot of were considered very carefully before here. > I think we should either create a separate column to segregate BAS > backend_writes, or just don't report them at all and report only the > non-BAS ones into pg_stat_bgwriter. > We can't not report them. One of the goals of pg_stat_bgwriter is to account for all writes out of the buffer cache. If there enough BAS writes on your system that them being lumped together is a serious problem, having them go missing altogether would be even worse. And any whacking around of pg_stat_bgwriter might as well fix that too. Do you think you could put together a quick test case that's similar to the ones you're seeing unfair accounting for here? This isn't quite buggy behavior, but a solid example I could test against showing it's a sketchy approach would be enough for me to incorporate a fix for it into this suggested redesign.
В списке pgsql-hackers по дате отправления: