Обсуждение: Fresh Restore - relation contains more than "max_fsm_pages"
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
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
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
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
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:Maybe a non-default FILLFACTOR was set on some tables/indexes?
> 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".
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