Re: Should heapam_estimate_rel_size consider fillfactor?

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
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 18:41:37
Message-ID: CADkLM=eSFK2dD8sR7gf7WP3WeS25yvCwWHPEqGmXfRu50HRQkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2023-06-14 18:46:48 trying again to get incremental backup
Previous Message Jeff Davis 2023-06-14 18:30:45 Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX