Re: To what extent should tests rely on VACUUM ANALYZE?
От | Tomas Vondra |
---|---|
Тема | Re: To what extent should tests rely on VACUUM ANALYZE? |
Дата | |
Msg-id | eb8c4530-2fcb-4c31-8b75-ec89a18b766b@enterprisedb.com обсуждение исходный текст |
Ответ на | [MASSMAIL]To what extent should tests rely on VACUUM ANALYZE? (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: To what extent should tests rely on VACUUM ANALYZE?
|
Список | pgsql-hackers |
On 3/28/24 16:00, Alexander Lakhin wrote: > ... > > Using the trick Thomas proposed in [1] (see my modification attached), I > could reproduce the failure easily on my workstation with no specific > conditions: > 2024-03-28 14:05:13.792 UTC client backend[2358012] > pg_regress/test_setup LOG: !!!ConditionalLockBufferForCleanup() > returning false > 2024-03-28 14:05:13.792 UTC client backend[2358012] > pg_regress/test_setup CONTEXT: while scanning block 29 of relation > "public.tenk2" > 2024-03-28 14:05:13.792 UTC client backend[2358012] > pg_regress/test_setup STATEMENT: VACUUM ANALYZE tenk2; > ... > relname | relpages | reltuples | autovacuum_count | autoanalyze_count > ---------+----------+-----------+------------------+------------------- > - tenk2 | 345 | 10000 | 0 | 0 > + tenk2 | 345 | 9996 | 0 | 0 > (1 row) > > So it looks to me like a possible cause of the failure, and I wonder > whether checks for query plans should be immune to such changes or results > of VACUUM ANALYZE should be 100% stable? > Yeah. I think it's good to design the data/queries in such a way that the behavior does not flip due to minor noise like in this case. But I'm a bit confused - how come the estimates do change at all? The analyze simply fetches 30k rows, and tenk only has 10k of them. So we should have *exact* numbers, and it should be exactly the same for all the analyze runs. So how come it changes like this? regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: