public inbox for [email protected]
help / color / mirror / Atom feedFrom: Corey Huinker <[email protected]>
To: Tomas Vondra <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Should heapam_estimate_rel_size consider fillfactor?
Date: Wed, 14 Jun 2023 14:41:37 -0400
Message-ID: <CADkLM=eSFK2dD8sR7gf7WP3WeS25yvCwWHPEqGmXfRu50HRQkA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
>
> 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.
>
I like this a lot. The reasoning is obvious, the fix is simple,it doesn't
upset any make-check-world tests, and in order to get a performance
regression we'd need a table whose fillfactor has been changed after the
data was loaded but before an analyze happens, and that's a narrow enough
case to accept.
My only nitpick is to swap
(usable_bytes_per_page * fillfactor / 100) / tuple_width
with
(usable_bytes_per_page * fillfactor) / (tuple_width * 100)
as this will eliminate the extra remainder truncation, and it also gets the
arguments "in order" algebraically.
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Should heapam_estimate_rel_size consider fillfactor?
In-Reply-To: <CADkLM=eSFK2dD8sR7gf7WP3WeS25yvCwWHPEqGmXfRu50HRQkA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox