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 1slEQz-006Aaq-Kr for pgsql-general@arkaria.postgresql.org; Mon, 02 Sep 2024 21:18:02 +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 1slEQy-002kyv-M9 for pgsql-general@arkaria.postgresql.org; Mon, 02 Sep 2024 21:18:00 +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 1slEQy-002kyn-BL for pgsql-general@lists.postgresql.org; Mon, 02 Sep 2024 21:18:00 +0000 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slEQv-000LV3-TY for pgsql-general@lists.postgresql.org; Mon, 02 Sep 2024 21:17:59 +0000 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-374c5bab490so1044853f8f.1 for ; Mon, 02 Sep 2024 14:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bowt-ie.20230601.gappssmtp.com; s=20230601; t=1725311876; x=1725916676; 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=TFjmJfvg5FXd/1pGxI2fT0INj4P5d+xrOljyslE0nJ0=; b=P9N2KfzFv4AMLnnBcAnoPr5uBiHhx14n7Ep48KMlQYo1UfScqiM11lA6q8tuq8kCwe IwxyBnqtctXzTABob4aKkBnOjtFVUEQvTmm5hxKoNATVtj/jYvCyEgFiSH5peiwhqxLT LDrwKYcdsCjT3TgYT80/6sG5r2G5+WRz8KkAJ07RScB+IOMQ06kI9oprE3Uf1gdtxM3q LQypXUeRfZ+D39Mafc8e1Z2dDOFWiuqJ4n9jYGTLjeiRFUXdZ7+DByjOnT7/CBxVe+o2 GID8Q7zZr+s3A1CSH84JhvAlowcQRpfTafjgynYsu96WANFBrKqsNmkZcuiuc47hKxOd KtgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725311876; x=1725916676; 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=TFjmJfvg5FXd/1pGxI2fT0INj4P5d+xrOljyslE0nJ0=; b=LGK5r9umboeQfwhmYq6f7yRYljdvLyilk41N9XqbZLmM2xNWSQ8djfE2JJD5yr5iDf wqYq0c+9agCp0QCdQGQYdqh4QdvyBV/J0ZU7xbYGz6eNo9NuMAA1zOIepojnHVB84wrN Gir7XDth4/DOItwdxKrhD/xhm9k3py4DCanLoPHMYTMd/C+Nf32WdSZgRynmvkDMzQpx SzoMVkPWtPh/7ZYl4aCH04m4rsbkzunrhnzp9V1KmSUkzmyZLZnzk/hpV9xONETHz6ly sAFzX4imoadRzPnROjLo9Q9BfAuk3sH5aFlGIku2Ql47fSZJsXe7uO89CMZdtvCrCjsJ yfRw== X-Forwarded-Encrypted: i=1; AJvYcCXk4g+BalK7dev+NDPfAykGJyzWq7l1CMlG6jLjHPTYfm+PJyoxSrH5wQ7K4YPNExj+LJjB4I9wmsMs2fBi@lists.postgresql.org X-Gm-Message-State: AOJu0Yx3wItgkB76v1ZvvpXB3L6mwaTGHzPdvN4IXI3CPI5zYQXdh+EB NBNxVT1qaVQXwHNe7jYFpGQwN9mUpLpWKwD9WBzKCjsacXlt3l07mYeqpaL7FNPS4d8U89WD1V8 scigJpE5TkJOykZgKjTZq5vvkLRLtJ5rlwm8yOw== X-Google-Smtp-Source: AGHT+IFkOGtzgjtlZwpUoGfSVWpuQybVLj5HH531Pjp9EQkFKIsSW4ayutbbUAVWljL5+XyaUPQo5yP7iecavp6L7Vw= X-Received: by 2002:a05:6000:480c:b0:374:d006:ffae with SMTP id ffacd0b85a97d-374d00701a8mr2797344f8f.6.1725311875979; Mon, 02 Sep 2024 14:17:55 -0700 (PDT) MIME-Version: 1.0 References: <3bda0d10-0d60-42b7-9600-abe23d54bb16@postgrespro.ru> <7bc8da54-fe4f-4ff2-aa4e-b54fc91df586@postgrespro.ru> In-Reply-To: From: Peter Geoghegan Date: Mon, 2 Sep 2024 17:17:30 -0400 Message-ID: Subject: Re: PG17 optimizations to vacuum To: Pavel Luzanov Cc: Melanie Plageman , "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 4:58=E2=80=AFPM Peter Geoghegan wrote: > On Mon, Sep 2, 2024 at 4:35=E2=80=AFPM Pavel Luzanov wrote: > > If it helps, without creating index on id column, the numbers will be > > much closer: > > Yes, avoiding all index vacuuming seems useful. It makes the test case > cleaner, since we don't have to think about the variability from the > TIDStore work (and from index vacuuming more generally). It just occurred to me that earlier versions don't have the HEAP_PAGE_PRUNE_MARK_UNUSED_NOW optimization added by commit c120550edb. Postgres 17 does have that optimization, though, so it should easily be able to write far fewer WAL records than earlier versions. And yet your revised no-indexes test case seems to show that Postgres 17 is doing slightly worse by that measure (and by others). --=20 Peter Geoghegan