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 foot?)
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: http://www.postgresql.org/mailpref/pgsql-hackers
