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 1slAsV-005iuy-8X for pgsql-general@arkaria.postgresql.org; Mon, 02 Sep 2024 17:30:11 +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 1slArU-00HK2v-B9 for pgsql-general@arkaria.postgresql.org; Mon, 02 Sep 2024 17:29:08 +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 1slArT-00HK2m-UC for pgsql-general@lists.postgresql.org; Mon, 02 Sep 2024 17:29:08 +0000 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slArO-000KKZ-0k for pgsql-general@lists.postgresql.org; Mon, 02 Sep 2024 17:29:07 +0000 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5c210e23651so4641315a12.3 for ; Mon, 02 Sep 2024 10:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725298141; x=1725902941; 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=it07OmL4tCqTs1CUrsEhndTvBRWvMB5dNGx7ewWLAp0=; b=j+ow13N/iBXsSpjxWjlNzW8b5/bIJsUnmCCDCYGGVvAeFSSWSpMNhppYb8S3DJL10P US9af1hILJ3wDVNyqFf8YaIRBf8iFnpHPMv2z0hoN8z40zy/icmkxwD2kVgmWF6Ha/y+ JtmBSR3gsG85Bik8D9abUgnPyPjPeSPsdki4dbA7XyaLGTlFpHacYIvKYL86RxakAAgR WaOiKDIZ/ZWF0N+SfWCrx7dIRaKS78jDTv3v2Is+2pB00KareHrvdAqUgJ/T73TGzUpO wOJQTtKGPfiM/5Pq1TcgkQPuXJvQkQMHpS+H6a9UGgY7LWSylaG/D8IwQmTCfHLPZRQa rsAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725298141; x=1725902941; 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=it07OmL4tCqTs1CUrsEhndTvBRWvMB5dNGx7ewWLAp0=; b=IXu3jHz2sv7B0aYtEDHS7tnSElQD98OM4mUVkIbe2aWkdAkdo3bSK29lVhPbGfniUI FcQFHDf+1uY5a8EFQAfdvkMS/CvDH1aL2324LUQSHXHi5/M7SBbYeinRqYEOEz1fUDan zETAsG6/X8JVPlb6fkhOJ57BZAjGrDPNYoyb97Snbgr4DLhh3tmMOoiQIJgyroGDZ4va ADfSBZAKhoziawbGif1Axbewjcr9diwqa7i95Lj3slOEowubcsJgIw0WctA+Iws2Bf1V w47ip7qKkS1C5+AOrlUAmolaKDSeiOHNmT9/AL5Q7HthDykf6f3JDExPb8mmWaAqaM0J wXuQ== X-Forwarded-Encrypted: i=1; AJvYcCV1kJpoNtia2+KtRWQRb3OBNdnR1LSCzsD445Kk84AVcKGsBE1MtcXVepwbiK70kZZulDFocHT44+lglHAV@lists.postgresql.org X-Gm-Message-State: AOJu0YyR3OYub2JVCfr/kl2VH8T8BMggpRAwHtaln4CM83Zv8KKknDyW KoEqk9zo4xGK9kSdKDOwV0uY/mQgmsIs/DByiqHUYE2ho+LUE3uW6+3ebYPaKBxuME6xFtZw4/W H0h3eomtiAUbNExR0V2e4zt1oWBI= X-Google-Smtp-Source: AGHT+IGFBB7c+TjCvn5SyVtti+wCsDz8hrc0IZ8BCQMnlc9FxY0tPxpaL8LkbntwYNzz13WoAB+3LK+C5LjMrwVzIhg= X-Received: by 2002:a05:6402:520b:b0:5c2:5251:bae5 with SMTP id 4fb4d7f45d1cf-5c25251bb42mr4181520a12.9.1725298140630; Mon, 02 Sep 2024 10:29:00 -0700 (PDT) MIME-Version: 1.0 References: <3bda0d10-0d60-42b7-9600-abe23d54bb16@postgrespro.ru> In-Reply-To: From: Melanie Plageman Date: Mon, 2 Sep 2024 13:28:49 -0400 Message-ID: Subject: Re: PG17 optimizations to vacuum To: Peter Geoghegan 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 Sun, Sep 1, 2024 at 6:00=E2=80=AFPM Peter Geoghegan wrote: > > On Sun, Sep 1, 2024 at 5:44=E2=80=AFPM Pavel Luzanov wrote: > > I see a perfectly working TID-store optimization. > > With reduced maintenance_work_mem it used only one 'vacuuming indexes' > > phase instead of 21 in v16. > > But I also expected to see a reduction in the number of WAL records > > and the total size of the WAL. Instead, WAL numbers have significantly > > degraded. > > > > What am I doing wrong? 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. - Melanie