From: | AP <pgsql(at)inml(dot)weebeastie(dot)net> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: 10.1: hash index size exploding on vacuum full analyze |
Date: | 2017-11-21 02:25:43 |
Message-ID: | 20171121022543.3eozjhbcq3vxbpk6@inml.weebeastie.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Nov 20, 2017 at 01:26:50PM +0530, Amit Kapila wrote:
> Another angle to look at it is that even if the values of relpages and
> reltuples is not updated why we get such a wrong estimation by
> estimate_rel_size. I think to some extent it depends on the schema of
> the table, so is it possible for you to share schema of the table.
Hi,
Schema's simple:
CREATE TABLE link (
datum_id BYTEA NOT NULL,
ids BYTEA NOT NULL
);
ALTER TABLE link ALTER COLUMN datum_id SET STATISTICS 10000;
ALTER TABLE link ALTER COLUMN ids SET STATISTICS 0;
ALTER TABLE link SET ( AUTOVACUUM_ANALYZE_SCALE_FACTOR = 0.001, AUTOVACUUM_VACUUM_SCALE_FACTOR = 0.001 );
CREATE INDEX ON link USING hash (datum_id) WITH ( FILLFACTOR = 90 );
That's for the live table. Then I move it aside and recreate the index
with FILLFACTOR = 100.
> > Tell me if you need me to keep the index around.
>
> I don't think so, but till we solve the problem there is no harm in
> keeping it if possible because one might want some information at a
> later stage to debug this problem. OTOH, if you have space crunch
> then feel free to delete it.
No worries. I'll keep it around for as long as I can.
AP
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-11-21 06:25:20 | Re: [BUGS] BUG #14890: Error grouping by same column twice using FDW |
Previous Message | Tanes Sriviroolchai | 2017-11-21 00:46:10 | Re: BUG #14919: Invalid column in sub select is still a valid select |