Re: Should heapam_estimate_rel_size consider fillfactor?
| От | Corey Huinker |
|---|---|
| Тема | Re: Should heapam_estimate_rel_size consider fillfactor? |
| Дата | |
| Msg-id | CADkLM=eSFK2dD8sR7gf7WP3WeS25yvCwWHPEqGmXfRu50HRQkA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Should heapam_estimate_rel_size consider fillfactor? (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
| Ответы |
Re: Should heapam_estimate_rel_size consider fillfactor?
|
| Список | 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
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.
В списке pgsql-hackers по дате отправления: