Re: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system

Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> I've checked how this worked in 9.2 (before the 9.3 patch that split the
> file per db), and back then last_statsrequest (transformed to
> request_time) was used to decide whether we need to write something. But
> now we do that by simply checking whether the list is empty.

Right. In effect, 9.3 moved the decision about "do we need to write stats
because of this request" from the main loop to pgstat_recv_inquiry()
... but we forgot to incorporate any check for whether the request was
already satisfied into pgstat_recv_inquiry(). We can do that, though,
as per either of the patches under discussion --- and once we do so,
maintaining DBWriteRequest.request_time seems a bit pointless.

It's conceivable that we'd try to implement merging of close-together
requests in a way that would take account of how far back the oldest
unsatisfied request is. But I think that a global oldest-request time
would be sufficient for that; we don't need to track it per-database.
In any case, it's hard to see exactly how to make that work without
putting a gettimeofday() call into the inner message handling loop,
which I believe we won't want to do on performance grounds. The previous
speculation about doing writes every N messages or when we have no input
to process seems more likely to lead to a useful answer.

regards, tom lane