Re: 10.1: hash index size exploding on vacuum full analyze
От | Teodor Sigaev |
---|---|
Тема | Re: 10.1: hash index size exploding on vacuum full analyze |
Дата | |
Msg-id | d465e05a-6022-354c-e001-181c61c6b090@sigaev.ru обсуждение исходный текст |
Ответ на | Re: 10.1: hash index size exploding on vacuum full analyze (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: 10.1: hash index size exploding on vacuum full analyze
Re: 10.1: hash index size exploding on vacuum full analyze |
Список | pgsql-bugs |
Hi! > I think if we update the stats in copy_heap_data after copying the > data, then we don't see such problem. Attached patch should fix the > issue. You can try this patch to see if it fixes the issue for you. I'm afraid I'm not able to reproduce the problem which patch should fix. What I did (today's master, without patch): autovacuum off pgbench -i -s 100 select relname, relpages, reltuples from pg_class where relname = 'pgbench_accounts'; relname | relpages | reltuples ------------------+----------+----------- pgbench_accounts | 163935 | 1e+07 vacuum full pgbench_accounts; # select relname, relpages, reltuples from pg_class where relname = 'pgbench_accounts'; relname | relpages | reltuples ------------------+----------+----------- pgbench_accounts | 163935 | 1e+07 I've tried to add hash index to that table and print notice about number of pages and tuples immediately after estimate_rel_size() in hashbuild(). hash index got right estimation even I deleted all rows before vacuum full. What am I doing wrong? Patch looks good except, seems, updating stats is better to move to swap_relation_files(), then it will work even for toast tables. -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
В списке pgsql-bugs по дате отправления: