We've seen reports occasionally of how the system reports that
max_fsm_pages needs to be increased to at least X, and then when the DBA
does so, it complains that some larger amount is needed --- one recent
report is here:
http://archives.postgresql.org/pgsql-admin/2006-06/msg00176.php
I finally
Hi, Tom,
Tom Lane wrote:
I think it's reasonable for vacuumlazy.c to track at most MaxFSMPages
pages as it's doing now --- but it should keep a separate count of the
total number of pages with at least threshold amount of free space, and
pass that as a separate argument to
Tom Lane wrote:
I think it's reasonable for vacuumlazy.c to track at most MaxFSMPages
pages as it's doing now --- but it should keep a separate count of the
total number of pages with at least threshold amount of free space, and
pass that as a separate argument to RecordRelationFreeSpace. This
Tom Lane wrote:
In fact, maybe vacuum should just throw a WARNING when it
finds a single rel with more than MaxFSMPages pages with useful free
space?
I fully agree with this. This (in particular, how many useful free
pages a rel has) is information a good DBA can make very good use of,
and is
On Thu, 21 Sep 2006, Tom Lane wrote:
We've seen reports occasionally of how the system reports that
max_fsm_pages needs to be increased to at least X, and then when the DBA
does so, it complains that some larger amount is needed --- one recent
report is here:
