Message-ID: <10ed61c0-a078-9bdf-9ff4-dca92ffd5315@enterprisedb.com>
Date: Mon, 3 Jul 2023 09:00:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: Should heapam_estimate_rel_size consider fillfactor?
To: Peter Eisentraut <peter@eisentraut.org>,
 Corey Huinker <corey.huinker@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <cf154ef9-6bac-d268-b735-67a3443debba@enterprisedb.com>
 <CADkLM=eSFK2dD8sR7gf7WP3WeS25yvCwWHPEqGmXfRu50HRQkA@mail.gmail.com>
 <63729d7a-cb1e-06af-a24e-27a8b93717ef@eisentraut.org>
Content-Language: en-US
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <63729d7a-cb1e-06af-a24e-27a8b93717ef@eisentraut.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/10ed61c0-a078-9bdf-9ff4-dca92ffd5315%40enterprisedb.com>
Precedence: bulk


On 7/3/23 08:46, Peter Eisentraut wrote:
> On 14.06.23 20:41, Corey Huinker wrote:
>>     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.
> 
> The fillfactor is in percent, so it makes sense to divide it by 100
> first before doing any further arithmetic with it.  I find your version
> of this to be more puzzling without any explanation.  You could do
> fillfactor/100.0 to avoid the integer division, but then, the comment
> above that says "integer division is intentional here", without any
> further explanation.  I think a bit more explanation of all the
> subtleties here would be good in any case.
> 

Yeah, I guess the formula should be doing (fillfactor / 100.0).

The "integer division is intentional here" comment is unrelated to this
change, it refers to the division by "tuple_width" (and yeah, it'd be
nice to have it explain why it's intentional).


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company