[Bug] unexpected reltuples number in pg_class after delete and vacuum

[congxuebin]

Cloudberry Database version

No response

What happened

After delete 15 rows and vacuum, the following query get unexpected 88 reltuples. But the test case would expect 85. Please confirm if this is incompatible change. Thanks.

SELECT relname, reltuples FROM pg_class WHERE relname = 'foo_index';

relname | reltuples
-----------+-----------
foo_index | 88

More detailed information, please see how to reproduce section.

What you think should happen instead

No response

How to reproduce

CREATE TABLE foo (a INT, b INT, c CHAR(128)) WITH (appendonly=true) DISTRIBUTED BY (a);
CREATE INDEX foo_index ON foo(b);
INSERT INTO foo SELECT i as a, i as b, 'hello world' as c FROM generate_series(1, 50) AS i;
INSERT INTO foo SELECT i as a, i as b, 'hello world' as c FROM generate_series(51, 100) AS i;
ANALYZE foo;
DELETE FROM foo WHERE a < 16;
VACUUM foo;
SELECT relname, reltuples FROM pg_class WHERE relname = 'foo_index';

You will get reltuples 88:

relname | reltuples
-----------+-----------
foo_index | 88
(1 row)

Operating System

centos7

Anything else

2 test cases failed due to this issue:
FAIL: UAOCompactionTestCase.test_stats
FAIL: UAOCOCompactionTestCase.test_stats

Are you willing to submit PR?

• Yes, I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct.

[lss602726449]

We shoud change the output result to 88 which is the same as GP. The reason is that we have already change the vacuum strategy for AO. We only vacuum for segno which hideRatio larger than gp_appendonly_compaction_threshold.

[congxuebin]

Thanks Shengsong for the confirmation. I would update the test case accordingly.