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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: less log level for success dynamic background workers for 9.5
Следующее
От: Amit Langote
Дата:
Сообщение: Re: UPSERT on partition