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 1slCwh-0060T5-PQ for pgsql-general@arkaria.postgresql.org; Mon, 02 Sep 2024 19:42:40 +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 1slCwe-001Ngv-UG for pgsql-general@arkaria.postgresql.org; Mon, 02 Sep 2024 19:42:37 +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 1slCwd-001Ngn-VJ for pgsql-general@lists.postgresql.org; Mon, 02 Sep 2024 19:42:36 +0000 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slCwW-000KnB-VZ for pgsql-general@lists.postgresql.org; Mon, 02 Sep 2024 19:42:34 +0000 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-374c4d4f219so1205331f8f.1 for ; Mon, 02 Sep 2024 12:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bowt-ie.20230601.gappssmtp.com; s=20230601; t=1725306147; x=1725910947; 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=NrmpZZjjl/nHmxAhesQDOT6vZCmZBSVEvQJhm7iHGak=; b=vmSDYbUYEIJTYYDQ/nKoIbLyM1S7FroqZRrrDMtTp0rA3WQ+2MJcfiakNoinSD+BtM QLUa2LudV8Rc3/en+NGI0eP5IgDdS9ftnSVKfAOznkCDz017uLVTB/3zen0OIf6FWDna 99NOuKH3SXqUXQlPsRKUumTJuckXAPFvI02z388/8aYPPv7uhkWrenLMomQQ0bk/GygC poXQWY9+0vjZfjVd9uGsCHRvrqpbaif8m2203EtszUaOXke91gbS9gn6xQGHm6EDGrcm kiRtkB+1ZAvOlf7uOn5VHe3kYhQBMlT/BFeR2Gm3h5uXrD6EEG1VGJZD+kOoRrDtYZwd tD/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725306147; x=1725910947; 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=NrmpZZjjl/nHmxAhesQDOT6vZCmZBSVEvQJhm7iHGak=; b=RUTQrsUPok4rKRA6uuogWcT5Ii5j6HmrdS0isd98GCojHr6k3Cq0t+WiH/9il9Ax0W aM5n9ymi3pMtOjgA2LZjwl81YaXw2lMR7djjOJbA96JtKMJmKQtGOxlwr4li85+Nx9I0 taMpjioyj0VbnfdItG/F0knirGHSI9r+pGiHHA12vvKM6z4B7e0tV/7ulNTAjg6ewCSZ v4aNlM23LqxZ9pnz8/TaJT9XyFEGcTLZy2WqDQXJlzsgjfA392u44m2Hh9SUZVf2cH1h rmKRq6pOhuR5aqU08ypZcMRk+499amabCjRnAcbi96YrXZIO6qlWGcrD6ZpFG4VcMClK wI7w== X-Forwarded-Encrypted: i=1; AJvYcCWkPC045nl+75/E3730lDZr12J396WuBPOl8yIgh5p5qOrqR8nZCI0In2w+8Ilv/j9CfJNs6r0XaugjIcEb@lists.postgresql.org X-Gm-Message-State: AOJu0Ywl5KuhF1Gh5flRlSWMdLYFX0X4uCU9np/1zPCmaOtP77xfw1VH H5LBUXCJJqKbTFTvr/8YHBYuExntRMPdjz2O3kfgIOpXA1JfBFtlHGwfh/3ZgHz515yuojjtK4B UNZ+kWs17YpBEFYbe8iRBtdcfH34ND+g2Kq/YVQ== X-Google-Smtp-Source: AGHT+IEvqbhRZljO0PygvH5iAAS+wTNurxCL36VybF0hirIMvZLC3TRoCoMf4QO2LPn9TOZwrh2SgF8pHkb/NUQ1fTA= X-Received: by 2002:adf:f2c7:0:b0:374:c0c9:d178 with SMTP id ffacd0b85a97d-374ecc67ba1mr711194f8f.9.1725306146882; Mon, 02 Sep 2024 12:42:26 -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 15:42:00 -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 3:23=E2=80=AFPM Melanie Plageman wrote: > This is roughly what I get for records by vacuum. Note that I prefixed > VACUUM with BTREE on master to indicate those records are from index > vacuuming. By default the headesc routine for records emitted by index > vacuuming prints just VACUUM -- perhaps it would be better to prefix > it. > > Note that these add up to almost the same thing. I don't know yet why > the number PRUNE_VACUUM_SCAN is different than PRUNE on 16. That is indeed surprising, given that Pavel's VACUUM VERBOSE output indicates that the number of heap tuples deleted is identical across versions. The output also strongly suggests that the same heap pages are pruned on both versions, since the "index scan needed: " line is also identical across versions. Might it be that the extra PRUNE_VACUUM_SCAN records originated in pages that only contained existing LP_UNUSED items when scanned by VACUUM? --=20 Peter Geoghegan