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 1uZcpR-005zn9-7F for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Jul 2025 21:59:49 +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 1uZcpN-004fyh-4m for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Jul 2025 21:59:45 +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 1uZcpM-004fyY-Hj for pgsql-hackers@lists.postgresql.org; Wed, 09 Jul 2025 21:59:45 +0000 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uZcpI-006jUv-1v for pgsql-hackers@lists.postgresql.org; Wed, 09 Jul 2025 21:59:44 +0000 Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-60c9d8a169bso456684a12.1 for ; Wed, 09 Jul 2025 14:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752098379; x=1752703179; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=V8uS74xy5+PtfXanPQuPZxBufJakpZBFrWtZgyDe8uU=; b=VljGnkY1ehoVrgb5Dmv0hiFM7kkXCSqMT6OxNtFGXtoVfR7vIs6IPEVUg2Ceu+RIp/ lIP123tLxRtHMkqBU8Eam8zbq0RYm90GIxp8qZ5k3KAUpsCldQmrM6Xc40NzyyxH7FIB k0IuMNw08IFCa/ZRIH1N9YCpie2UbITCLZbASPL8oYyWwq13aiJ01PGDvoyfh9S5XTpt 3+f8TVLbYdQTBSIx8MjlixjsiwvkGvqorsBFYdA+eabKyY9kaqemFLtgFZTyWKaSy7hf sPbw9wJADS9kdXGNcHYOWJFrOrd1dLe0HSjKgKVITok9oUZyh+2IYeZTZQyX21GxMBNH DCOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752098379; x=1752703179; h=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=V8uS74xy5+PtfXanPQuPZxBufJakpZBFrWtZgyDe8uU=; b=l/Ed8BGkeq9eDFP8sDWo8IsBhSwgi0qJ+4mm3OQgudMJXXJENvPT1XpplP38j1+s6z NTBMbmy3KiZaUuStIM1iTpWlnYkmjZ8Z5Cc/ij9C9aYcizpSWqI+Tn8isqKGZhGl9DmQ 9smPXo0Q1m26gl5VP99wpsYzxwVv+zZgXJWLQydSg37a0ocPU0SgWqFyJoRCGw4N9jFA C/2ofwOu8Jl4GUlIuvcy1PLe/RMsAWtsAiARZZrF5jgBshcDnSxCo5xmFcNLTAbQFp1x vEXLG2HVjxbFDHyQ76K2ulpUPT4ouvF+s1q5WT185/R3NcSQT5NP65+VW29uDiMMszqj Fzdw== X-Gm-Message-State: AOJu0YyhOyW+FgGTRU/h2a/s2aXpr1TH/C7h1XVnWJaZcgoKOctPs9em M4GnXs3L7thy3TIcS5eFdwDvWWHFqJkdyji+MsUJlrtyTBd4VgStKuKRCm2B+K4mLo4b9AfFb/Z p2/XjsubtQtGBRBr+cDJLjBe6Zr4RmroqlA51 X-Gm-Gg: ASbGncuG0muDnrhB/AcOJFHIgbv3/u9/txbxC9grNWP1jhXcLPcAoZgSsLah4z9mhIJ i7kM5Es9auN9swC0y1UwHwIUG/voo4wDDayxChNcEtpaTBrn63jG85GHZUSWIPEtSpI0y66ZWyv n1W6ssYebyliQKqv2g2xI1PUxl1Im+rVUzEGhDyEU2qL8= X-Google-Smtp-Source: AGHT+IGB9D20sdVqLtBgml24cFAKJfRZbQ76fI9cQnHWeO7hzEQm0YBu0U0DmhH7LYUUL402ZrUgaHoAG1dPxkRl5eY= X-Received: by 2002:a05:6402:1f0a:b0:607:26b4:6959 with SMTP id 4fb4d7f45d1cf-611c84b9685mr148878a12.7.1752098379026; Wed, 09 Jul 2025 14:59:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Melanie Plageman Date: Wed, 9 Jul 2025 17:59:26 -0400 X-Gm-Features: Ac12FXylvTB7udchNQzTQ5sIGOoHbQKVohlKwuCJkEoOX4isEUIQC-9sR_vN06s Message-ID: Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) To: PostgreSQL Hackers Cc: Andres Freund , Robert Haas Content-Type: multipart/mixed; boundary="0000000000007eb0740639863165" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007eb0740639863165 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 26, 2025 at 6:04=E2=80=AFPM Melanie Plageman wrote: > > Rebased in light of recent changes on master: This needed another rebase, and, in light of the discussion in [1], I've also removed the patch to add heap wrappers for setting pages all-visible. More notably, the final patch (0012) in attached v3 allows on-access pruning to set the VM. To do this, it plumbs some information down from the executor to the table scan about whether or not the table is modified by the query. We don't want to set the VM only to clear it while scanning pages for an UPDATE or while locking rows in a SELECT FOR UPDATE. Because we only do on-access pruning when pd_prune_xid is valid, we shouldn't need much of a heuristic for deciding when to set the VM on-access -- but I've included one anyway: we only do it if we are actually pruning or if the page is already dirty and no FPI would be emitted. You can see it in action with the following: create extension pg_visibility; create table foo (a int, b int) with (autovacuum_enabled=3Dfalse, fillfacto= r=3D90); insert into foo select generate_series(1,300), generate_series(1,300); create index on foo (a); update foo set b =3D 51 where b =3D 50; select * from foo where a =3D 50; select * from pg_visibility_map_summary('foo'); The SELECT will set a page all-visible in the VM. In this patch set, on-access pruning is enabled for sequential scans and the underlying heap relation in index scans and bitmap heap scans. This example can exercise any of the three if you toggle enable_indexscan and enable_bitmapscan appropriately.