Re: 10.1: hash index size exploding on vacuum full analyze

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, AP <pgsql(at)inml(dot)weebeastie(dot)net>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: 10.1: hash index size exploding on vacuum full analyze
Date: 2017-12-15 14:38:50
Message-ID: d465e05a-6022-354c-e001-181c61c6b090@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message rameez.iqbal 2017-12-15 14:42:32 BUG #14980: initddb fails (Issue with postgresql-9.3 initd config)
Previous Message dbaber 2017-12-15 10:26:04 BUG #14979: PostGres does not start at reboot