Re: Relstats after VACUUM FULL and CLUSTER

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Erik Nordström <erik(at)timescale(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Relstats after VACUUM FULL and CLUSTER
Date: 2025-05-22 20:08:28
Message-ID: CAA5RZ0vmJ1zYxUNzq0Btq1CYVy_yVTRzOXEAkhkQ+8P249zOSg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> You need a concurrent transaction to recreate the situation. I am attaching an isolation test to show the behavior,

Thanks! That helps.
Indeed heapam_relation_copy_for_cluster and heapam_index_build_range_scan
are counting HEAPTUPLE_RECENTLY_DEAD ( tuples removed but cannot be removed )
different. In heapam_relation_copy_for_cluster they are considered live and in
heapam_index_build_range_scan they are considered dead.

in heapam_relation_copy_for_cluster
```
case HEAPTUPLE_RECENTLY_DEAD:
*tups_recently_dead += 1;
/* fall through */
case HEAPTUPLE_LIVE:
/* Live or recently dead, must copy it */
isdead = false;
break;
```

In both cases, he recently dead tuples must be copied to the table or index, but
they should not be counted towards reltuples. So, I think we need to fix this in
heapam_relation_copy_for_cluster by probably subtracting
tups_recently_dead from num_tuples ( which is the value set in
pg_class.reltuples )
after we process all the tuples, which looks like the best fix to me.

--
Sami Imseih
Amazon Web Services (AWS)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2025-05-22 20:10:34 Re: queryId constant squashing does not support prepared statements
Previous Message Masahiko Sawada 2025-05-22 20:06:50 Re: Assert("vacrel->eager_scan_remaining_successes > 0")