Re: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
Alvaro Herrera <alvherre@2ndquadrant.com>
Date: 2016-05-27T01:55:17Z
Lists: pgsql-hackers
On Thu, May 26, 2016 at 6:43 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > On 05/26/2016 10:10 PM, Tom Lane wrote: >> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: >> In view of 52e8fc3e2, there's more or less no case in which we'd be >> writing stats without writing stats for the shared catalogs. So I'm >> tempted to propose that we try to reduce the overhead by merging the >> shared-catalog stats back into the global-stats file, thereby >> halving the filesystem metadata traffic for updating those. > > [...] > > That being said, I'm not opposed to merging the shared catalog into the > global-stats file - it's not really a separate database so having it in a > separate file is a bit weird. While looking at this stuff, to be honest I got surprised that shared relation stats are in located in a file whose name depends on InvalidOid, so +1 from here as well to merge that into the global stats file. -- Michael
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Split pgstat file in smaller pieces
- 187492b6c2e8 9.3.0 cited