From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Should heapam_estimate_rel_size consider fillfactor? |
Date: | 2023-06-14 19:53:53 |
Message-ID: | 20230614195353.kke26ol7vyrykdad@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-06-11 14:41:27 +0200, Tomas Vondra wrote:
> While testing some stuff, I noticed heapam_estimate_rel_size (or rather
> table_block_relation_estimate_size it calls) ignores fillfactor, so that
> for a table without statistics it ends up with reltuple estimate much
> higher than reality. For example, with fillfactor=10 the estimate is
> about 10x higher.
>
> I ran into this while doing some tests with hash indexes, where I use
> fillfactor to make the table look bigger (as if the tuples were wider),
> and I ran into this:
>
> drop table hash_test;
> create table hash_test (a int, b text) with (fillfactor=10);
> insert into hash_test select 1 + ((i - 1) / 10000), md5(i::text)
> from generate_series(1, 1000000) s(i);
> -- analyze hash_test;
> create index hash_test_idx on hash_test using hash (a);
>
> select pg_size_pretty(pg_relation_size('hash_test_idx'));
>
> If you run it like this (without the analyze), the index will be 339MB.
> With the analyze, it's 47MB.
>
> This only happens if there are no relpages/reltuples statistics yet, in
> which case table_block_relation_estimate_size estimates density from
> tuple width etc.
>
> So it seems the easiest "fix" is to do ANALYZE before creating the index
> (and not after it, as I had in my scripts). But I wonder how many people
> fail to realize this - it sure took me a while to realize the indexes
> are too large and even longer what is causing it. I wouldn't be very
> surprised if many people had bloated hash indexes after bulk loads.
>
> So maybe we should make table_block_relation_estimate_size smarter to
> also consider the fillfactor in the "no statistics" branch, per the
> attached patch.
Seems like a good idea - I can't think of a reason why we shouldn't do so.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-06-14 19:56:44 | Re: Let's make PostgreSQL multi-threaded |
Previous Message | Andres Freund | 2023-06-14 19:51:39 | Re: Let's make PostgreSQL multi-threaded |