Обсуждение: Fresh Restore - relation contains more than "max_fsm_pages"

Поиск
Список
Период
Сортировка

Fresh Restore - relation contains more than "max_fsm_pages"

От
"Maton, Brett"
Дата:
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"

От
Craig Ringer
Дата:
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"

От
"Maton, Brett"
Дата:
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