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.96) (envelope-from ) id 1wFG2c-004te0-2E for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Apr 2026 18:41:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wFG2b-00A6YA-2H for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Apr 2026 18:41:45 +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.96) (envelope-from ) id 1wFG2b-00A6Xv-1M for pgsql-hackers@lists.postgresql.org; Tue, 21 Apr 2026 18:41:45 +0000 Received: from mail-yx1-xb12d.google.com ([2607:f8b0:4864:20::b12d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wFG2Z-0000000283x-1Uyc for pgsql-hackers@lists.postgresql.org; Tue, 21 Apr 2026 18:41:44 +0000 Received: by mail-yx1-xb12d.google.com with SMTP id 956f58d0204a3-6501c9903edso4716934d50.1 for ; Tue, 21 Apr 2026 11:41:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776796903; cv=none; d=google.com; s=arc-20240605; b=ZP54Ohf1qY9JjV5BV60LcoSbfN0qGjtD0b0E7EO2o3r1nOcYJuxtiQ4sbiz+mrvg9R Ks+grxcKgHbhFeeXFdlcSInUIFu2qd7ANujOWMJcdF+11PvnuX+lQCT4QfOLOdPpfxOt N4FRY2DvdngW7I4y3UrxcoTYnASWurugObAzc0T2u+7UOjEe6QWvbeY7x0nnpDgBPe2V vmkXvLScsMbZWMEkMUlPIGhMSaagLVUkrSVYUp1LQ6nmvLSs9XcpljNxCbBb0ltE609w cBXeAYcRl9CGlGGLQKe4bY1uuG6zevzXvYhVQ/dTTRabPS8j8o441DTkyfriv6EpMhPV 8mVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=uNGEd2sVr4PbLz3RA3YvHNqt2FCWGDmQdPK3hQWQ4fY=; fh=g679eFSvrLw6t3jMxy1U7zDMp1JHvjquVnI7LTD4PE4=; b=k+TB+QsrK3uyHhWyWtQUBPsPOhonBFTD8Z6ytS7VUPvxXO2aojSBXylpyKkWAX4T7h ME4OeIbNQpx7lkBH7jn9B6Z0RKffOMvAHynh4NBVoIYx18cXUv/v3naU7g9GypyFpBzg kgdBg7lMUeaZbJAIuy/0bkX5rNNGw0GW/W4+T/GPS2sPo0vlkU3pYgkfbhWVeD0sTX0X YmbrJik7cyY1L2RjmL9ws1PTopRpvKIk33Bautg+Yn2GOQwvTxZGWpQyP5Bw6PGRl7uZ 2nBL3oXN5U70d8xwOuvSR09J6D8hxDcYfFeJzQeotSoAm+XKasuuGz1azBhlTwZwXJKG 99dg==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776796903; x=1777401703; 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=uNGEd2sVr4PbLz3RA3YvHNqt2FCWGDmQdPK3hQWQ4fY=; b=IG75zi2IRYTq6WB7gPbw23dwsG6hcSdW+1TxbczMj8Kq6Eja6noD8v+859DC7qISNG JOyG5wySN28zVbvCS5TfKDtywDkL12XJZTfZwOrv8zSk5AdKSVHqU/ZzqWNOdt3XaiOk thCwb8zXN7WPWvk83Vqu1iMSZoGAGMSXlIIV0pOvuwOy9XaKVQrOjH4M2+CbGupMVUXj cM8t61cqOiPU5DfwUBNNvb7bNjeXy0+Bkfj3BPJdbE5/qdBHMWuSttHD5iftDnJ3A4U/ aup6MwAqg0CAPZg/fZ70I4SiUYdDpXHgc2STLbNsBITpgTxyg2lwJtaKQF2aRIlIVTRo oyUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776796903; x=1777401703; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uNGEd2sVr4PbLz3RA3YvHNqt2FCWGDmQdPK3hQWQ4fY=; b=npHNLXkaD9Bj3iZml4EF61YFI0LSGGchk3qFRVM0v1MWbJih3RLFJUdCQ/3gNCTmZ4 klajsTlABR6WKgoGL2RPPv6puiScxj4qGTbNu4m0CSXbtDlHSK9bST0SuV6LFUvX3Bou VvEuKbfXNmeZJrTyUaG4nCbRyygvf5zIhvVSWvfLWynEbrrtGqx7rV7FzUOMLKm6FReh VfDhWJMbrgQ/xTz/3nbgPEvt53qK5oeHGIGXtLHlCiaubdaM/uBWUjFJz8Ic+z69lpuX awp5/o/Wuslzq5hIm6pkxdJfMTNEQoPww/vGKUX+ht8HCkQajc/0SyFOhNVn5yhtg653 XUkA== X-Forwarded-Encrypted: i=1; AFNElJ/B6u+Eaa5ojxTBSLTcT6jH3zCfFPi/CzpQSCnbBmublQWnaoEISlDVKiKZTep0x7LDeVULcezL69ScVULl@lists.postgresql.org X-Gm-Message-State: AOJu0YxE51pU4oh5n9qylH12vOee7RnyDe4eXG1lCiz+Qds87GPYifN4 rlxwxY3XjMTNiZLbzPNoi/c0g6ONqlXx+xusuAAKhvW8hskxRJa1olveuXc1+wRYTMUbN+kLnyc VgdpOXyLHwl5w0P38AxtR4lIE+sPT3Nc= X-Gm-Gg: AeBDiesmkLhbWWKADb91VpQScumfxAl4oZJR9nMssHQWI34ne3uyUEpPOhbWDYNOjXQ wXQ8RkeM6BomGlaVSeN/RA71wegQZ9F4xY651EU4ZRC7BNqRn6HQL6LsThG+UbU2AZSQyCYlrX6 hKQejO6FoOf/YEivp1YxYRJruHCPDZZCpLU/wfYqZRGAwYWPqRBdSO74tkDNadSs/JPxPvXEb0s gV3CO9oGMDAOncrvL6goKHYTo09kvBDLaBZtIsLtzyTQ+ntYge193lfIkBFUAeVH+bosMap/XbY FXStiJcICyv4+Kfrzb4P0/POm4jwQo07/J8WE6ZWIolcdQu5pg1rpyV0cFgQdFhwWks+cyGX1ub LY7ekpVQLETHtmU8mbKI= X-Received: by 2002:a05:690e:1a27:b0:652:f423:47e5 with SMTP id 956f58d0204a3-65310a0b58fmr13365064d50.42.1776796902891; Tue, 21 Apr 2026 11:41:42 -0700 (PDT) MIME-Version: 1.0 References: <2be31f17-5405-4de9-8d73-90ebc322f7d8@vondra.me> <97529f5a-ec10-46b1-ab50-4653126c6889@gmail.com> <46733d68-aec0-4d09-8120-4c66b87047a4@gmail.com> <71277259-264e-4983-a201-938b404049d7@gmail.com> In-Reply-To: From: Melanie Plageman Date: Tue, 21 Apr 2026 14:41:30 -0400 X-Gm-Features: AQROBzDTbzvzmQnRlPTaqlN_ELwrSlJGfpjXBsqKFZSL3Uju-WhQ3Yv0lvieoKM Message-ID: Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) To: Alexander Lakhin Cc: Andres Freund , Tomas Vondra , David Rowley , Kirill Reshke , Chao Li , Andrey Borodin , Xuneng Zhou , Robert Haas , PostgreSQL Hackers , 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, Apr 20, 2026 at 4:28=E2=80=AFPM Melanie Plageman wrote: > > I think we can avoid having relallvisible updated by doing two things: > 1) moving the analyze test_mode above the create index because the > create index will scan the table and could set pages all-visible and > then the analyze may update the statistics > 2) create the table with autovacuum_enabled =3D false to avoid vacuum > and analyze running after any of the other table scans may set some > pages all-visible So, I don't love that this test relies on pg_class not having been updated to reflect relallvisible. But, I don't see a good way around this. If we need the "bad plan" to be a seq scan, then pg_class.relallvisible can't be updated. As long as only analyze and vacuum will update pg_class.relallvisible, we can preserve the desired behavior by disabling autovacuum/analyze for the table and analyzing it (to get reltuples/relpages) before any scan that could set the VM for the pages. So, I've done this and committed it in 85ae8ab0533. - Melanie