Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side
Дата
Msg-id 7b5b8d27-7500-772c-9fe5-384f51de38b0@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers

On 2020/03/20 3:39, Andres Freund wrote:
> Hi,
> 
> On 2020-03-19 17:21:38 +0900, Fujii Masao wrote:
>> Pushed! Thanks!
> 
> FWIW, I'm a bit doubtful that incuring the overhead of this by default
> on everybody is a nice thing. On filesystems with high latency and with
> a lot of small relations the overhead of stating a lot of files can be
> almost as high as the actual base backup.

Yeah, so if we receive lots of complaints like that during beta and
RC phases, we should consider to change the default behavior.

Also maybe I should measure how long the estimation takes on the env
where, for example, ten thousand tables (i.e., files) exist, in order to
whether the default behavior is really time-consuming or not?

Regards,

-- 
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Wait event that should be reported while waiting for WALarchiving to finish
Следующее
От: Atsushi Torikoshi
Дата:
Сообщение: Re: type of some table storage params on doc