On Mon, Nov 14, 2011 at 2:02 PM, Jaime Casanova <ja...@2ndquadrant.com> wrote:
> On Wed, Nov 9, 2011 at 7:58 AM, Alvaro Herrera
> <alvhe...@commandprompt.com> wrote:
>> Excerpts from Jaime Casanova's message of mar nov 08 18:12:25 -0300 2011:
>>> On Sun, Nov 6, 2011 at 5:38 AM, Magnus Hagander <mag...@hagander.net> wrote:
>>> >
>>> > Looks pretty useful.
>>> thanks for the review, attached is a new version of it
>> Note that AFAIK you shouldn't update the 1.0 extension script ... you
>> have to create a 1.1 version (or whatever), update the default version
>> in the control file, and create an 1.0--1.1 script to upgrade from the
>> original version to 1.1.
> good point... fixed that...
> a question i have is: are we supposed to let the old script (1.0) around?

Since the syntax to install a non-default version is supported, I
would argue the old script should be kept.
CREATE extension pageinspect with version "1.0"

This patch applies and builds cleanly.  It works either for "CREATE
EXTENSION" from scratch, or for updating from the prior version with

It seems to be using the buffer ring strategy as advertised.

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.  (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

As noted by Greg, the documentation calls it "total amount of free
free [sic] space" when that is not what is reported.  However, it also
is not reporting a percentage, but rather a decimal fraction.  The
reported value should be multiplied by 100, especially if the docs are
going to be changed to call it a percentage.

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.

I have no insight into how to handle toast tables, or non-superusers.
I had thought that toast tables had names of their own which could be
used, but I could not figure out how to do that.

Even if there are other ways to get approximately the same
information, this functionality seems to be a natural thing to have in
the pageinspect extension.



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

Reply via email to