Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side
Date
Msg-id 7b5b8d27-7500-772c-9fe5-384f51de38b0@oss.nttdata.com
Whole thread Raw
In response to Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Wait event that should be reported while waiting for WALarchiving to finish
Next
From: Atsushi Torikoshi
Date:
Subject: Re: type of some table storage params on doc