On Tue, Oct 23, 2018 at 9:42 AM John Naylor <jcnaylor@gmail.com> wrote:
> A case could be made for setting the threshold to 4, since not having
> 3 blocks of FSM in shared buffers exactly makes up for the 3 other
> blocks of heap that are checked when free space runs out.
That doesn't seem like an unreasonable argument. I'm not sure whether
the right threshold is 4 or something a little bigger, but I bet it's
not very large. It seems important to me that before anybody thinks
about committing this, we construct some kind of destruction case
where repeated scans of the whole table are triggered as frequently as
possible, and then run that test with varying thresholds. I might be
totally wrong, but I bet with a value as large as 32 you will be able
to find cases where it regresses in a big way.
We also need to think about what happens on the standby, where the FSM
is updated in a fairly different way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company