Date: Thu, 19 Sep 2024 07:54:21 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: "Imseih (AWS), Sami" <simseih@amazon.com>,
	Masahiko Sawada <sawada.mshk@gmail.com>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
	Robert Haas <robertmhaas@gmail.com>
Subject: Re: Track the amount of time waiting due to cost_delay
Message-ID: <ZuvYrUDwsGgKtlKJ@ip-10-97-1-34.eu-west-3.compute.internal>
References: <ZmreasV0BKZ5BHIM@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZnbIIUQpFJKAJx2W@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZnlPZZZJCRu/8fka@ip-10-97-1-34.eu-west-3.compute.internal>
 <42B4800A-D8D0-4734-930A-4D94D0EA90C7@amazon.com>
 <8D4DC535-1C51-44A9-ABDD-420F975AE8A9@amazon.com>
 <ZoI3rS2BdNi+kCWS@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZsSQnS9OW9EWSOk4@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZtVJCIu1MvS214po@ip-10-97-1-34.eu-west-3.compute.internal>
 <Ztk6yqPYAzAM7bkf@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZutAdT9aIpHOlloy@nathan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZutAdT9aIpHOlloy@nathan>
Archived-At: <https://www.postgresql.org/message-id/ZuvYrUDwsGgKtlKJ%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

Hi,

On Wed, Sep 18, 2024 at 04:04:53PM -0500, Nathan Bossart wrote:
> On Thu, Sep 05, 2024 at 04:59:54AM +0000, Bertrand Drouvot wrote:
> > Please find attached v6, a mandatory rebase due to catversion bump conflict.
> > I'm removing the catversion bump from the patch as it generates too frequent
> > conflicts (just mention it needs to be done in the commit message).
> 
> v6 looks generally reasonable to me.

Thanks for looking at it!

> I think the
> nap_time_since_last_report variable needs to be marked static, though.

Agree.

> One thing that occurs to me is that this information may not be
> particularly useful when parallel workers are used.  Without parallelism,
> it's easy enough to figure out the percentage of time that your VACUUM is
> spending asleep, but when there are parallel workers, it may be hard to
> deduce much of anything from the value.

I think that if the number of parallel workers being used are the same across
runs then one can measure "accurately" the impact of some changes (set
vacuum_cost_delay=... for example) on the delay. Without the patch one could just
guess as many others factors could impact the vacuum duration (load on the system,
i/o latency,...).

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com