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 1slB9k-005l0C-3y for pgsql-general@arkaria.postgresql.org; Mon, 02 Sep 2024 17:48:01 +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 1slB9j-00HaPn-9u for pgsql-general@arkaria.postgresql.org; Mon, 02 Sep 2024 17:47:59 +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 1slB9i-00HaPa-Oi for pgsql-general@lists.postgresql.org; Mon, 02 Sep 2024 17:47:59 +0000 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slB9g-000KRQ-MK for pgsql-general@lists.postgresql.org; Mon, 02 Sep 2024 17:47:58 +0000 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-42c7bc97423so22425955e9.0 for ; Mon, 02 Sep 2024 10:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bowt-ie.20230601.gappssmtp.com; s=20230601; t=1725299274; x=1725904074; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=J1S9d4Iu+nzyxfHuovRHADrwaAT4nLwFPT0DSwjqr7s=; b=micbuv3tNyj7N6uaWxnMVREAA2ou2jqLJqsf9Dzhou4OahRBjW0IoOwBc9YN/Ym2si +JoTUa/3OytDLAJv+c9FjIGj8+qeer7WS9Ze6vSQAN5EleTWhdF5MGYGBkJXWf0lwSta EIFKuNa/8KIoy7eCRnIJmZqaVHxerHuEVP9jXK36DfkRD5DzRxyrKbcHOoNReE5SmtYD Pb8LP4EXIfeIiLO1V0RmJsHsx/e2GXbm6nH3O7btyIHBzyyBq8Psv18LERwJfVGnnx/+ VJPXJBfc4z7LCTk4EKPHssJdwQ5nOj9LC0xxf9QgOGuWX7CHFfPitSK2YH8C9ZZ5ylsC 2Kxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725299274; x=1725904074; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=J1S9d4Iu+nzyxfHuovRHADrwaAT4nLwFPT0DSwjqr7s=; b=V6rey+Jp1e22cITlFH+QCvihJMbaozZ8OvtASug6yHINbWEuP1BC/MNMRejpBT4xqo s6BU5bCj+9DU58yt6Twpagmn5FIeOaL9TOffSQbMm0RbyAaqnsN3zU6pnVeY6ziEn/6X i2qUOUsVExXkwc4KFH+lxEtJ/YPdRexn8Mtw0uM8ME9ZQXv/23I0lDYVsv78XOTpiUV0 icJNdXGKlTSLJscKm2eahSUEEffjdWQM39fjjxZtBZz+Vx3x1HKJXfgb17jTQBKjHcYx DDE624MNt8ncxk/WChjm0RY68hDKMifxNhshI82ocFnXPwyVJkd06YhR56nr0Vp/kvoo /Sjw== X-Forwarded-Encrypted: i=1; AJvYcCXSeWQ/2Mx52yc42mjQLLiy5txk+IRAIS2dRYRkYQ4hZle0LuMILG1A8qxZuLqi6uERDoW/bkMip/mzTE8Q@lists.postgresql.org X-Gm-Message-State: AOJu0YwmjaW7ylR+uoorGGA4lWKhRR6zvD6/Znqgons7dwcU0osdCHHK 3UUjVGtjOUkNHVJFysMkKDjUFEcVGbCgQjRJAugzmurNiKNvIAe3PmByKVvs/Ig1stm3hdaaG/C 0US7MbE9FR43bWsa8XJ9MJVa5rWNZwVJ/95wQbw== X-Google-Smtp-Source: AGHT+IEJn2Yozrh/ktkXYHdUlC5fzd6DubAXlexr7fTMZaw7TS91XrrnAYEGPwpL0hukaPtSWSt6PnEYh0unvX41mSo= X-Received: by 2002:a05:600c:a03:b0:426:5f09:cf53 with SMTP id 5b1f17b1804b1-42bb01b9c73mr147731565e9.15.1725299274208; Mon, 02 Sep 2024 10:47:54 -0700 (PDT) MIME-Version: 1.0 References: <3bda0d10-0d60-42b7-9600-abe23d54bb16@postgrespro.ru> In-Reply-To: From: Peter Geoghegan Date: Mon, 2 Sep 2024 13:47:28 -0400 Message-ID: Subject: Re: PG17 optimizations to vacuum To: Melanie Plageman Cc: Pavel Luzanov , "pgsql-generallists.postgresql.org" , Heikki Linnakangas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Sep 2, 2024 at 1:29=E2=80=AFPM Melanie Plageman wrote: > I'll investigate more tomorrow, but based on my initial investigation, > there appears to be some interaction related to how much of the > relation is in shared buffers after creating the table and updating > it. If you set shared_buffers sufficiently high and prewarm the table > after the update, master has fewer WAL records reported by vacuum > verbose. Fewer of what specific kind of WAL record? All of the details about useful work done by VACUUM were identical across versions. It was only the details related to WAL, buffers, and CPU time that changed. Perhaps I'm not thinking of something obvious. Maybe it's extra VISIBILITY records? But I'd expect the number of VISIBILITY records to match the number of pages frozen, given these particulars. VACUUM VERBOSE at least shows that that hasn't changed. --=20 Peter Geoghegan