Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
Date: 2022-01-15 02:43:08
Message-ID: CAH2-WzmL-Xc9wYecy7Z_WV18e8c9yioSMBLpJoF9Ew+5LuSWrA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 13, 2022 at 1:27 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> Admittedly you may see a blip from this -- you might notice that the
> final relfrozenxid value for that one single VACUUM isn't quite as new
> as you'd like. But then the next VACUUM should catch up with the
> stable long term average again. It's hard to describe exactly why this
> effect is robust, but as I said, empirically, in practice, it appears
> to be robust. That might not be good enough as an explanation that
> justifies committing the patch series, but that's what I see. And I
> think I will be able to nail it down.

Attached is v6, which like v5 is a rebased version that I'm posting to
keep CFTester happy. I pushed a commit that consolidates VACUUM
VERBOSE and autovacuum logging earlier (commit 49c9d9fc), which bitrot
v5. So new real changes, nothing to note.

Although it technically has nothing to do with this patch series, I
will point out that it's now a lot easier to debug using VACUUM
VERBOSE, which will directly display information about how we've
advanced relfrozenxid, tuples frozen, etc:

pg(at)regression:5432 =# delete from mytenk2 where hundred < 15;
DELETE 1500
pg(at)regression:5432 =# vacuum VERBOSE mytenk2;
INFO: vacuuming "regression.public.mytenk2"
INFO: finished vacuuming "regression.public.mytenk2": index scans: 1
pages: 0 removed, 345 remain, 0 skipped using visibility map (0.00% of total)
tuples: 1500 removed, 8500 remain (8500 newly frozen), 0 are dead but
not yet removable
removable cutoff: 17411, which is 0 xids behind next
new relfrozenxid: 17411, which is 3 xids ahead of previous value
index scan needed: 341 pages from table (98.84% of total) had 1500
dead item identifiers removed
index "mytenk2_unique1_idx": pages: 39 in total, 0 newly deleted, 0
currently deleted, 0 reusable
index "mytenk2_unique2_idx": pages: 30 in total, 0 newly deleted, 0
currently deleted, 0 reusable
index "mytenk2_hundred_idx": pages: 11 in total, 1 newly deleted, 1
currently deleted, 0 reusable
I/O timings: read: 0.011 ms, write: 0.000 ms
avg read rate: 1.428 MB/s, avg write rate: 2.141 MB/s
buffer usage: 1133 hits, 2 misses, 3 dirtied
WAL usage: 1446 records, 1 full page images, 199702 bytes
system usage: CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s
VACUUM

--
Peter Geoghegan

Attachment Content-Type Size
v6-0004-Loosen-coupling-between-relfrozenxid-and-tuple-fr.patch application/octet-stream 28.8 KB
v6-0005-Freeze-tuples-early-to-advance-relfrozenxid.patch application/octet-stream 9.5 KB
v6-0003-Consolidate-VACUUM-xid-cutoff-logic.patch application/octet-stream 11.3 KB
v6-0001-Simplify-lazy_scan_heap-s-handling-of-scanned-pag.patch application/octet-stream 46.0 KB
v6-0002-Improve-VACUUM-instrumentation.patch application/octet-stream 14.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-01-15 02:54:04 Re: Refactoring of compression options in pg_basebackup
Previous Message Julien Rouhaud 2022-01-15 02:31:23 Re: Add 64-bit XIDs into PostgreSQL 15