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 1slDlY-0066SH-Rk for pgsql-general@arkaria.postgresql.org; Mon, 02 Sep 2024 20:35:14 +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 1slDlW-0023ij-Du for pgsql-general@arkaria.postgresql.org; Mon, 02 Sep 2024 20:35:10 +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 1slDlV-0023ib-V3 for pgsql-general@lists.postgresql.org; Mon, 02 Sep 2024 20:35:10 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1slDlT-000LZn-4z for pgsql-general@lists.postgresql.org; Mon, 02 Sep 2024 20:35:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1725309305; bh=KlAcL02D1nb4piS3tCvihnoj6mIsorq1xCIhmeinM38=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=Lfer031j3rdjuAL4D7IMXRRBBl1poUTNMubmZQI6gXhKxAxnsekfjy239XZ2dEcjE F3gEf+cjl4hydc4NNPo7j5A1XJm5MsGJK8H8im3QqUlWSbV6DqVRg09Hp0UgtowJhf nb4MEQQYIHlFu1OLDyruyHpPhnBANlB5sdyFA80uw20xt6pWaVtfcIZHCasglbFegj d/m+sk2Az8uV9n3a4un9OTGN2YbfawadDe4OkQnUt46L9pUPGKdNgflArt+mES53bt bdlygKtU+ocvyU983DtOkfML/DsHbxzL4lDVCQtZoGTlKgzL2//xm8w2dPdVhUNsVp SHpruymxvCEjQ== Received: from [192.168.0.104] (unknown [5.35.115.211]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: p.luzanov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 4329E602AF; Mon, 2 Sep 2024 23:35:05 +0300 (MSK) Content-Type: multipart/alternative; boundary="------------WVdevr0MSlGu0Nd0zwn6nLwu" Message-ID: <7bc8da54-fe4f-4ff2-aa4e-b54fc91df586@postgrespro.ru> Date: Mon, 2 Sep 2024 23:35:04 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: PG17 optimizations to vacuum To: Melanie Plageman , Peter Geoghegan Cc: "pgsql-generallists.postgresql.org" , Heikki Linnakangas References: <3bda0d10-0d60-42b7-9600-abe23d54bb16@postgrespro.ru> Content-Language: en-US, ru-RU From: Pavel Luzanov In-Reply-To: X-KSMG-AntiPhishing: NotDetected, bases: 2024/09/02 20:12:00 X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2024/09/02 19:12:00 #26510068 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------WVdevr0MSlGu0Nd0zwn6nLwu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02.09.2024 22:23, Melanie Plageman wrote: > For some reason I stopped being able to reproduce Pavel's case. I repeated the test on another computer, but compared master with v15. The results are the same. The test can be simplified as follows: CREATE TABLE t(id integer) WITH (autovacuum_enabled = off); INSERT INTO t SELECT gen.id FROM generate_series(1,3_500_000) gen(id); CREATE INDEX t_id ON t(id); VACUUM FREEZE t; UPDATE t SET id = id + 1; VACUUM FREEZE VERBOSE t; My results (only line with WAL info from the last VACUUM command). master: WAL usage: 119583 records, 37231 full page images, 272631468 bytes v15: WAL usage: 96565 records, 47647 full page images, 217144602 bytes If it helps, without creating index on id column, the numbers will be much closer: master: WAL usage: 78502 records, 22090 full page images, 196215494 bytes v15: WAL usage: 77437 records, 30872 full page images, 152080268 bytes -- Pavel Luzanov Postgres Professional:https://postgrespro.com --------------WVdevr0MSlGu0Nd0zwn6nLwu Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.09.2024 22:23, Melanie Plageman wrote:
For some reason I stopped being able to reproduce Pavel's case.
I repeated the test on another computer, but compared master with v15.
The results are the same. The test can be simplified as follows:

CREATE TABLE t(id integer) WITH (autovacuum_enabled = off);
INSERT INTO t SELECT gen.id FROM generate_series(1,3_500_000) gen(id);
CREATE INDEX t_id ON t(id);
VACUUM FREEZE t;
UPDATE t SET id = id + 1;
VACUUM FREEZE VERBOSE t;

My results (only line with WAL info from the last VACUUM command).

master:
WAL usage: 119583 records, 37231 full page images, 272631468 bytes

v15:
WAL usage: 96565 records, 47647 full page images, 217144602 bytes


If it helps, without creating index on id column, the numbers will be
much closer:

master:
WAL usage: 78502 records, 22090 full page images, 196215494 bytes

v15:
WAL usage: 77437 records, 30872 full page images, 152080268 bytes
-- 
Pavel Luzanov
Postgres Professional: https://postgrespro.com
--------------WVdevr0MSlGu0Nd0zwn6nLwu--