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

On 17.2.2013 06:46, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> I've been thinking about this (actually I had a really weird dream about
>> it this night) and I think it might work like this:
>>
>> (1) check the timestamp of the global file -> if it's too old, we need
>>     to send an inquiry or wait a bit longer
>>
>> (2) if it's new enough, we need to read it a look for that particular
>>     database - if it's not found, we have no info about it yet (this is
>>     the case handled by the dummy files)
>>
>> (3) if there's a database stat entry, we need to check the timestamp
>>     when it was written for the last time -> if it's too old, send an
>>     inquiry and wait a bit longer
>>
>> (4) well, we have a recent global file, it contains the database stat
>>     entry and it's fresh enough -> tadaaaaaa, we're done
>
> Hmm, yes, I think this is what I was imagining.  I had even considered
> that the timestamp would be removed from the per-db file as you suggest
> here.

So, here's v10 of the patch (based on the v9+v9a), that implements the
approach described above.

It turned out to be much easier than I expected (basically just a
rewrite of the pgstat_read_db_statsfile_timestamp() function.

I've done a fair amount of testing (and will do some more next week) but
it seems to work just fine - no errors, no measurable decrease of
performance etc.

regards
Tomas Vondra