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

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

In response to

Browse pgsql-bugs by date

  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