On 06/24/2015 07:54 PM, Jeff Janes wrote:
Were the stories (or the experience which lead to the stories) on 9.3 or later? Do they have a good way to reproduce it for testing purposes?
The per-db split can only improve things if there actually are multiple databases, and if the objects are somehow evenly distributed among them. If there's a single database, or if most of the objects are in a single database (but stored in multiple schemas, for example), it does not help much. So it's trivially to reproduce the previous issues.
When I was testing the stat file split patch, one thing I noticed is that on the ext4 file system, when you atomically replace a file by renaming a file over the top of an existing file name, it will automatically fsync the file being renamed. This is exactly what we don't want in the case of the temp stats files. But there seems to be no way to circumvent it, other than unlinking the target file before the rename (which of course defeats the point of atomic replacement), or moving to a different filesystem for the stats files.
Interesting. I don't think unlinking is a good idea - my understanding is that we do it this way because rename is supposed to be atomic or something like that. I don't know whether addressing this filesystem feature is worth it, or if pgstat.c is the right place to do that.
-- Tomas Vondra http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
