Thread: Fresh Restore - relation contains more than "max_fsm_pages"

Fresh Restore - relation contains more than "max_fsm_pages"

From
"Maton, Brett"
Date:
postgresql v8.3.14

Can anyone help me identify why a vacuum on clean pg_restore database would give this warning?
I've been told that the database was restored and not been touched since, i.e. no inserts / updates or deletes.  So I'm curious as to why it appears to have been created with excessive "holes".

The table is pretty big 499GB and contains mostly encrypted text fields.

Also, for some reason the max_fsm_pages parameter has been set to 1,500,000

Thanks in advance for any help.

Brett

Re: Fresh Restore - relation contains more than "max_fsm_pages"

From
Craig Ringer
Date:
On 28/07/11 18:13, Maton, Brett wrote:
> postgresql v8.3.14
>
> Can anyone help me identify why a vacuum on clean pg_restore database
> would give this warning?
> I've been told that the database was restored and not been touched
> since, i.e. no inserts / updates or deletes.  So I'm curious as to why
> it appears to have been created with excessive "holes".

Maybe a non-default FILLFACTOR was set on some tables/indexes?

Or - especially if restore was done as schema followed by data rather
than all in one - the index creation and subsequent updates freed too
many pages?

Personally, I'd recommend moving to 8.4 or above, where you no longer
need worry about the free space map at all.

--
Craig Ringer

Re: Fresh Restore - relation contains more than "max_fsm_pages"

From
"Maton, Brett"
Date:
Thanks Craig,

  Is there a query I can run to check if the Fill Factor was changed ?
  The restore was executed as a single pg_restore, rather than schema then data,,,,

  I'm trying to get PG upgraded to 8.4, but you know it is......

Brett

On 29 July 2011 04:56, Craig Ringer <craig@postnewspapers.com.au> wrote:
On 28/07/11 18:13, Maton, Brett wrote:
> postgresql v8.3.14
>
> Can anyone help me identify why a vacuum on clean pg_restore database
> would give this warning?
> I've been told that the database was restored and not been touched
> since, i.e. no inserts / updates or deletes.  So I'm curious as to why
> it appears to have been created with excessive "holes".

Maybe a non-default FILLFACTOR was set on some tables/indexes?

Or - especially if restore was done as schema followed by data rather
than all in one - the index creation and subsequent updates freed too
many pages?

Personally, I'd recommend moving to 8.4 or above, where you no longer
need worry about the free space map at all.

--
Craig Ringer