Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sHLb0-006Kfs-Fi for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Jun 2024 10:52:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sHLay-00GOiS-H9 for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Jun 2024 10:52:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sHLay-00GOiJ-7R for pgsql-hackers@lists.postgresql.org; Wed, 12 Jun 2024 10:52:49 +0000 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sHLaw-001Fsz-3v for pgsql-hackers@lists.postgresql.org; Wed, 12 Jun 2024 10:52:48 +0000 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-35f22d3abf1so3158350f8f.1 for ; Wed, 12 Jun 2024 03:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718189565; x=1718794365; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3VLfaeYS1LT6AWntaJdLAhibpcfOtywUUNkDkf4G/m0=; b=Gw//RhnL1CS7eRY73bUrdr5Hy+ORFG3Ej4L4QNu2pYKWQBiVf+CrLD5LOA3lqkGabM vuLbcVPb7rg142cfpgGxZBzYotJGqaElqP+QXy1qyB3LzppfeXp4wi29nQflAFpH90g6 GcgQdY5S7AxAq/YyAO9gKI0meQsR+c/70M/1A9ipQ1FW8PL+iKP3e/wiIAFp/p7gH6K2 KkQ6VEjlNH2Q4CuXqjfTIRXatlFvf9mTTI+ZgJsaxlugw6eyo+T00hM8A2YjJLfnBkGx 72CKsY5HUilN4b97xU9V+jHgJXK9s8ZaI8C3oZj/lqUhE5gqANPXiU+kj+qTZy7xtgRt hI9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718189565; x=1718794365; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3VLfaeYS1LT6AWntaJdLAhibpcfOtywUUNkDkf4G/m0=; b=GF5qm0M6IhM/63tRSJsegYyfUaoB6JJq+MFwS00AR2x2RM6/CDeEM4PdywpNWAhqCl 8TtWzHJWHD/l9HsQJoSs2U92/6EPeEqoEsCdlayfmi4eeH75ybCbDsQwoq5b293ZA5cC Ib71r3Xjm50B5lcYhChzJIceVNXdU7ho76G2CXnW+VVoCiiSvmNkWoqWGpQ5yXHnS7e7 s2ItS41waBBadCEZR6Y7yk2vA34TeT8afnnCfWz18ZmUs3U9YL+2stDh+kJV+qxd4EWj +KFBHSbp8hDMVjEL/ht3GxrJF5YI6aw1b5RRNB70/V6MOOErBfAccw0JRuVSvSv3wDLP 2nHA== X-Forwarded-Encrypted: i=1; AJvYcCX19ebmm+ZjDXYQ09Lr+vWkQPsNtPIvXWNNL7791Q8EhAi1Ww98tFqmUcSMykCbOuu7qeVnCrYIDFqUS8N1trByVOgygjxue7IZEo7hJ+OtWYl9 X-Gm-Message-State: AOJu0YxWUjLv1ZHmyO+A5PjdiC6CSvrYu76xJPgwS9ou3Umu3IkHTLs+ NfhlIDgNOV3b4/sDx+06Nomee9Dxv/rAWEJ//+dJw+kaP+ll3MjQ X-Google-Smtp-Source: AGHT+IE0rw8/X/8IGvu6QZ+aOJb1hQLZz8JWEFoLqjhT/E5me6UWxMXOZfMaCMNQwdva2hMrSXbuEg== X-Received: by 2002:a5d:52c2:0:b0:360:7057:c1bb with SMTP id ffacd0b85a97d-3607057c279mr59597f8f.8.1718189564522; Wed, 12 Jun 2024 03:52:44 -0700 (PDT) Received: from ip-10-97-1-34.eu-west-3.compute.internal (ec2-15-236-134-5.eu-west-3.compute.amazonaws.com. [15.236.134.5]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-35f1a7c663asm11014208f8f.115.2024.06.12.03.52.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Jun 2024 03:52:44 -0700 (PDT) Date: Wed, 12 Jun 2024 10:52:42 +0000 From: Bertrand Drouvot To: Nathan Bossart Cc: Robert Haas , pgsql-hackers@lists.postgresql.org Subject: Re: Track the amount of time waiting due to cost_delay Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Tue, Jun 11, 2024 at 11:40:36AM -0500, Nathan Bossart wrote: > On Tue, Jun 11, 2024 at 07:25:11AM +0000, Bertrand Drouvot wrote: > > So I think that in v2 we could: 1) measure the actual wait time instead, 2) > > count the number of times the vacuum slept. We could also 3) reports the > > effective cost limit (as proposed by Nathan up-thread) (I think that 3) could > > be misleading but I'll yield to majority opinion if people think it's not). > > I still think the effective cost limit would be useful, if for no other > reason than to help reinforce that it is distributed among the autovacuum > workers. I also think it can be useful, my concern is more to put this information in pg_stat_progress_vacuum. What about Sawada-san proposal in [1]? (we could create a new view that would contain those data: per-worker dobalance, cost_lmit, cost_delay, active, and failsafe). [1]: https://www.postgresql.org/message-id/CAD21AoDOu%3DDZcC%2BPemYmCNGSwbgL1s-5OZkZ1Spd5pSxofWNCw%40mail.gmail.com Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com