On 11/25/2011 04:42 PM, Jeff Janes wrote:
It reports space that is free exclusively for updates as being free.
In other words, it considers space free even if it is reserved against
inserts in deference to fillfactor.  This is in contrast to
pg_freespace, which only reports space available for inserts as being
available.  I think this is reasonable behavior, but it is subtle and
should perhaps be documented.

Ah, that's right, this is why I first wandered this specific path. Ignoring fillfactor seems to have even more downsides as I see it. Certainly deserves a doc improvement, as well as fixing the description of the value so it's clearly a ratio rather than a true percentage.

(Is it common to use fill factors other
than the default in the first place?  Do we assume that people using
fillfactor are sophisticated enough not to shot themselves in the

It's not common, and I think anyone who sets fillfactor themselves would understand the downside. The bigger risk are people who inherit designs from others that use this feature, but the new person doesn't understand it. If using this feature calls attention to a problem there that prompts an investigation, I'd see that as a good thing, rather than a foot shot.

Unless I am missing something, all indexes are handled via a procedure
designed for BTree indices, "GetBTRelationFreeSpace".  I don't know
that the ultimate behavior of this is wrong, but it seems unusual.  If
I get some more time, I will try to explore what is actually going on
when called on other types of indexes.

This I think I'll punt back toward Jaime, as well as asking "did you have a plan for TOAST here?"

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to