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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
