Re: pg_stat_*_columns?
От | Tomas Vondra |
---|---|
Тема | Re: pg_stat_*_columns? |
Дата | |
Msg-id | 558B400D.8070900@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: pg_stat_*_columns? (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: pg_stat_*_columns?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: