Skip site navigation (1) Skip section navigation (2)

Re: Measuring relation free space

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Measuring relation free space
Date: 2011-11-28 10:40:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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?"

In response to


pgsql-hackers by date

Next:From: Yeb HavingaDate: 2011-11-28 10:41:24
Subject: Re: patch for type privileges
Previous:From: Greg SmithDate: 2011-11-28 10:13:52
Subject: CommitFest 2011-11 Post-Tryptophan Progress Report

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group