public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexander Lakhin <[email protected]>
To: Melanie Plageman <[email protected]>
To: Andres Freund <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: Chao Li <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: Xuneng Zhou <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Date: Sat, 18 Apr 2026 18:00:00 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAAKRu_Z8Ry_ynNBPAzs_Ry3MQi9NaBgt1ccLgwRsDbxWpocaBg@mail.gmail.com>
<CAAKRu_Zj8G4T=HN3QSY7iQvkKSQk-k1fq+eJkjCBNqoSg63z+Q@mail.gmail.com>
<CAAKRu_bgP-DMZs=D2j2N0+U9+uWU5cVagw-yZLOuhYbWj_KwnA@mail.gmail.com>
<itvgqc6vncbjsjfmrptfvkkeg5vqzhalaguya2z77t6c6ctpc3@wsdrgbn4bxaa>
<CAAKRu_aWMyGB=zg5W7+RUtor6TqsiOwHXSL7Dg4TUUiTSzzcpw@mail.gmail.com>
<[email protected]>
<CAAKRu_Ypa7-JGVR+fstDxU5Cfitk_rf5ijdaqwtoPkztursufA@mail.gmail.com>
<CAAKRu_ZrDadxmGepBwPZ03yAKnMxwsHYn8SK9Gg7VqigLLVUWg@mail.gmail.com>
<CAApHDvqAOeOwCKh9g0gfxWa040=Hyc7_oA=C59rjod8kXJDWyw@mail.gmail.com>
<CAAKRu_Yt76_HdfR6DtK_wtkSNSj9=VxSV_npt+6T2R=zTzp1Pg@mail.gmail.com>
<CAAKRu_atv6zA274m8Ysgbfn49c0NbdvHT7nXvd9kroZKnFq8Dg@mail.gmail.com>
<CAApHDvq_R-gNXu+06GQW6w_HaEMh1pezsyiCh7GNhgh+h0UqMw@mail.gmail.com>
<CAAKRu_YfoGTHNn0XxA+dCPj9hyO96vO4Eb+awRR6T8m22qC6ww@mail.gmail.com>
<[email protected]>
Hello Melanie and Andres,
03.04.2026 08:00, Alexander Lakhin wrote:
>
> 31.03.2026 19:19, Melanie Plageman wrote:
>> Thanks for the reply! I have committed the patches in this thread and
>> marked the CF entry accordingly.
>
> I've come across an interesting failure produced starting from 378a21618:
> ...
I've discovered one more behaviour change introduced in 378a21618. I
investigated a yesterday's skink failure [1]:
# --- /home/bf/bf-build/skink-master/HEAD/pgsql/contrib/btree_gist/expected/enum.out 2025-06-23 20:17:56.295775456 +0200
# +++ /home/bf/bf-build/skink-master/HEAD/pgsql.build/testrun/btree_gist/regress/results/enum.out 2026-04-17
22:35:37.212061309 +0200
# @@ -83,12 +83,10 @@
#
# EXPLAIN (COSTS OFF)
# SELECT count(*) FROM enumtmp WHERE a >= 'g'::rainbow;
# - QUERY PLAN
# ------------------------------------------------
# + QUERY PLAN
# +------------------------------------------------
# Aggregate
# - -> Bitmap Heap Scan on enumtmp
# - Recheck Cond: (a >= 'g'::rainbow)
# - -> Bitmap Index Scan on enumidx
# - Index Cond: (a >= 'g'::rainbow)
# -(5 rows)
# + -> Index Only Scan using enumidx on enumtmp
# + Index Cond: (a >= 'g'::rainbow)
# +(3 rows)
#
# 1 of 32 tests failed.
pgsql.build/testrun/btree_gist/regress/log/postmaster.log contains
2026-04-17 22:35:36.909 CEST autovacuum worker[4020330] LOG: automatic analyze of table
"regression_btree_gist.public.enumtmp"
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
buffer usage: 128 hits, 0 reads, 0 dirtied
WAL usage: 2 records, 0 full page images, 322 bytes, 0 full page image bytes, 0 buffers full
system usage: CPU: user: 0.05 s, system: 0.00 s, elapsed: 0.11 s
and managed to reproduce it locally under Valgrind on a slowed down VM so
that the enum test takes ~10 sec: With
+select c.relname,c.relpages,c.reltuples,s.autovacuum_count,s.autoanalyze_count
+from pg_class c
+left join pg_stat_all_tables s on c.oid = s.relid
+where c.relname in ('enumtmp', 'enumidx');
added to the test for diagnostics and the test repeated 100 times, I got:
...
ok 46 - enum 10635 ms
ok 47 - enum 10559 ms
# diff -U3 /home/vagrant/postgres/contrib/btree_gist/expected/enum.out
/home/vagrant/postgres/contrib/btree_gist/results/enum.out
# --- /home/vagrant/postgres/contrib/btree_gist/expected/enum.out 2026-04-18 11:41:17.224063241 +0000
# +++ /home/vagrant/postgres/contrib/btree_gist/results/enum.out 2026-04-18 11:52:43.870049782 +0000
# @@ -91,18 +91,16 @@
# where c.relname in ('enumtmp', 'enumidx');
# relname | relpages | reltuples | autovacuum_count | autoanalyze_count
# ---------+----------+-----------+------------------+-------------------
# - enumtmp | 3 | 595 | 0 | 0
# + enumtmp | 3 | 595 | 0 | 1
# enumidx | 4 | 595 | |
# (2 rows)
#
# EXPLAIN (COSTS OFF)
# SELECT count(*) FROM enumtmp WHERE a >= 'g'::rainbow;
# - QUERY PLAN
# ------------------------------------------------
# + QUERY PLAN
# +------------------------------------------------
# Aggregate
# - -> Bitmap Heap Scan on enumtmp
# - Recheck Cond: (a >= 'g'::rainbow)
# - -> Bitmap Index Scan on enumidx
# - Index Cond: (a >= 'g'::rainbow)
# -(5 rows)
# + -> Index Only Scan using enumidx on enumtmp
# + Index Cond: (a >= 'g'::rainbow)
# +(3 rows)
#
not ok 48 - enum 10596 ms
ok 49 - enum 11693 ms
ok 50 - enum 11098 ms
...
# 6 of 131 tests failed.
I could also reproduce the same diff with just:
--- a/contrib/btree_gist/sql/enum.sql
+++ b/contrib/btree_gist/sql/enum.sql
@@ -40,2 +40,3 @@ SELECT count(*) FROM enumtmp WHERE a > 'g'::rainbow;
+ANALYZE enumtmp;
EXPLAIN (COSTS OFF)
It's not reproduced at 378a21618~1, though.
Could you please look if this can be fixed?
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2026-04-17%2019%3A10%3A50
Best regards,
Alexander
view thread (143+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox