29.03.2024 11:59, Alexander Lakhin wrote:
>
> But it looks like subselect is not the only test that can fail due to
> vacuum instability. I see that create_index also suffers from cranky
> ConditionalLockBufferForCleanup() (+if (rand() % 10 == 0)
> return false; ), although it placed in parallel_schedule before
> sanity_check, so this failure needs another explanation:
> - QUERY PLAN
> --------------------------------------------------------
> - Index Only Scan using tenk1_thous_tenthous on tenk1
> - Index Cond: (thousand < 2)
> - Filter: (tenthous = ANY ('{1001,3000}'::integer[]))
> -(3 rows)
> + QUERY PLAN
> +--------------------------------------------------------------------------------------
> + Sort
> + Sort Key: thousand
> + -> Index Only Scan using tenk1_thous_tenthous on tenk1
> + Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
> +(4 rows)
I think that deviation can be explained by the fact that cost_index() takes
baserel->allvisfrac (derived from pg_class.relallvisible) into account for
the index-only-scan case, and I see the following difference when a test
run fails:
relname | relpages | reltuples | relallvisible | indisvalid | autovacuum_count | autoanalyze_count
----------------------+----------+-----------+---------------+------------+------------------+-------------------
- tenk1 | 345 | 10000 | 345 | | 0 | 0
+ tenk1 | 345 | 10000 | 305 | | 0 | 0
Best regards,
Alexander