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 1sH6Xy-003JCl-Km for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jun 2024 18:48:43 +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 1sH6Wy-008hBc-3F for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jun 2024 18:47:40 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sH6Wx-008hBU-NE for pgsql-hackers@lists.postgresql.org; Tue, 11 Jun 2024 18:47:40 +0000 Received: from mail-io1-xd33.google.com ([2607:f8b0:4864:20::d33]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sH6Wr-000prJ-Qm for pgsql-hackers@lists.postgresql.org; Tue, 11 Jun 2024 18:47:39 +0000 Received: by mail-io1-xd33.google.com with SMTP id ca18e2360f4ac-7e252b2cfd8so236602939f.0 for ; Tue, 11 Jun 2024 11:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718131653; x=1718736453; 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=tQHNqqI7D7CUOWVZHbZevMQExe9hdbbW4+55hL5SySY=; b=PdKlX1Ej3Fqx4Ltv5RLGG0I3dZ2/dOiuz0/3uGTJ6aMvY56SMt27uVSs9nszKw7RJ+ 1/ppd9dcNb2IyXOoaculaZys8ExYSBrwtKxKERK2RCBheiahcL9Davsro/I3xxZbWlKJ Snvc6UXbMUdezdDIIRZ2hXDsvB0syXsobc7FEYnOa4UERFmunzi+6zZeN6GfEuCFpoez XDExGZnaNskJRYnLmPts/I+mdr6SPmxB7cnHIlYvRaXQmsH7SfzRXqPg6NjFHnGTgIPr d1una/qZitxWDNKKkrH15Z2GgKbADzJ+PmjL1rX3pu8Ql13UaVGazc68v+eZfTqxXK7U en/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718131653; x=1718736453; 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=tQHNqqI7D7CUOWVZHbZevMQExe9hdbbW4+55hL5SySY=; b=SNFmuy7/5v2xEWUNjB6Odj/bjI19NCHKLFgm+ob8EA97+YFD1H91FyG4gMfsYErySV QoHI+X3h5xvFsk/54QuG7WbKBsqww7/Y8smvkzPx2vDAtKhRdeDYRtvjLMNITajfhvhr 8pLYOi1PqX6AH61v2A249rXzuFKrjKo2VkpUVzyM7gfeOnm4AGWvB5t64DJuLkJtlwd+ RACl2EthcHoAhXqoapPlQlBGYKUOETebPM8gtAY9qpYSBHoPCuKzXuAz/bEDg/+Wd8v0 fs9a37t9m/Oa8mpbSKmrQw+L2G0OkPGAak1tVVJesrT4Px9MsS82md0TWEw32ZrdixGd NPOA== X-Forwarded-Encrypted: i=1; AJvYcCVLuz/sRC4k9iTcVSygl8XpY8QR0BrtULMzm0dAZ/0p0mBLrYHTHPKAg7Gkktg2cv/EWwVN+NF4UIbFhM0QIwxkED2aMVIab3pKjRnlWDSPlqU4 X-Gm-Message-State: AOJu0YwjeylLT3+x6P5zlGZ6M35fky5KtIuPFVVUdLQddYQxbd9o+pjf 9Ip2ucusaKSm1jJXo4dzysMUh9yW5Nv2Ym2DhnEkJFaMG4Xb2QPL X-Google-Smtp-Source: AGHT+IE7Wplwd2f9AavfttgfPARYccHeSqlCHuHsg4xzh26cqvI07yIlQnql2OdSMmKcXwVdxFBjAQ== X-Received: by 2002:a05:6602:2b8d:b0:7eb:4957:ea5b with SMTP id ca18e2360f4ac-7eb57215ad4mr1552826639f.11.1718131651722; Tue, 11 Jun 2024 11:47:31 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-7eb7e6eb2cdsm150568039f.48.2024.06.11.11.47.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jun 2024 11:47:31 -0700 (PDT) Date: Tue, 11 Jun 2024 13:47:29 -0500 From: Nathan Bossart To: "Imseih (AWS), Sami" Cc: Robert Haas , Bertrand Drouvot , "pgsql-hackers@lists.postgresql.org" Subject: Re: Track the amount of time waiting due to cost_delay Message-ID: References: <0EA474B6-BF88-49AE-82CA-C1A9A3C17727@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0EA474B6-BF88-49AE-82CA-C1A9A3C17727@amazon.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jun 11, 2024 at 06:19:23PM +0000, Imseih (AWS), Sami wrote: >> I'm not convinced that reporting the number of waits is useful. If we >> were going to report a possibly-inaccurate amount of actual waiting, >> then also reporting the number of waits might make it easier to figure >> out when the possibly-inaccurate number was in fact inaccurate. But I >> think it's way better to report an accurate amount of actual waiting, >> and then I'm not sure what we gain by also reporting the number of >> waits. > > I think including the number of times vacuum went into sleep > will help paint a full picture of the effect of tuning the vacuum_cost_delay > and vacuum_cost_limit for the user, even if we are reporting accurate > amounts of actual sleeping. > > This is particularly true for autovacuum in which the cost limit is spread > across all autovacuum workers, and knowing how many times autovacuum > went to sleep will be useful along with the total time spent sleeping. I'm struggling to think of a scenario in which the number of waits would be useful, assuming you already know the amount of time spent waiting. Even if the number of waits is huge, it doesn't tell you much else AFAICT. I'd be much more likely to adjust the cost settings based on the percentage of time spent sleeping. -- nathan