Re: New statistics for WAL buffer dirty writes

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Satoshi Nagayasu <snaga(at)uptime(dot)jp>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New statistics for WAL buffer dirty writes
Date: 2012-08-21 15:41:00
Message-ID: CA+TgmoZwaEOfAT0Rhk99s3JBwRqEigjVrurcGooVq33rakiSAw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 11, 2012 at 6:11 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> However, I do think we will want to add a way to query for the time of
> the last reset, as other monitoring features are going that way.

That should be easy to add.

> Is it OK that the count is reset upon a server restart?

I think it's OK. The reason why many of our stats are kept in the
stats file is because we have a limited amount of shared memory and
therefore can't guarantee (for example) that there's enough to keep
stats about EVERY table, since the number of tables is unlimited.
However, in cases where the data to be stored is fixed-size, and
especially when it's fixed-size and small, there's a lot of sense to
keeping the data in shared memory rather than sending stats collector
messages. It's a lot less overhead, for one thing. Maybe at some
point someone will want to devise a way to hibernate such stats to
disk at shutdown (or periodically) and reload them on startup, but it
doesn't seem like a must-have to me.

Other opinions may vary, of course.

> I'll marked it as waiting on author, for the documentation and reset
> time.

Yeah, we definitely need some documentation.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2012-08-21 15:44:44 Re: Slow tab completion w/ lots of tables
Previous Message Andres Freund 2012-08-21 15:31:27 Re: huge tlb support