pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: max_fsm_pages question
4+ messages / 4 participants
[nested] [flat]
* Re: max_fsm_pages question
@ 2003-07-15 22:09 Josh Berkus <josh@agliodbs.com>
0 siblings, 0 replies; 4+ messages in thread
From: Josh Berkus @ 2003-07-15 22:09 UTC (permalink / raw)
To: Joseph Shraibman <joseph@xtenit.com>; +Cc: pgsql-performance
Joe,
> Regarding the document at
> http://www.varlena.com/GeneralBits/Tidbits/perf.html#maxfsmp
>
> In section 3.3 you say max_fsm_pages should be set to the number of pages
> that vacuum reports. Does that apply to table pages only or both table and
> index pages? Because I'm finding my index pages are a lot more than the
> table pages.
Depends on which version you're using. As of 7.4 (now in beta), both ... this
is a major feature for 7.4, which should reduce the need to REINDEX
significantly.
For 7.3.3 and earlier, table pages only.
--
Josh Berkus
Aglio Database Solutions
San Francisco
^ permalink raw reply [nested|flat] 4+ messages in thread
* max fsm pages question
@ 2008-07-08 19:13 Radhika S <radhika.sambamurti@gmail.com>
2008-07-08 19:24 ` Re: max fsm pages question Bill Moran <wmoran@collaborativefusion.com>
0 siblings, 1 reply; 4+ messages in thread
From: Radhika S @ 2008-07-08 19:13 UTC (permalink / raw)
To: pgsql-performance
Hi,
when i issued the vaccuum cmd, I recieved this message:
echo "VACUUM --full -d ARSys" | psql -d dbname
WARNING: relation "public.tradetbl" contains more than
"max_fsm_pages" pages with useful free space
HINT: Consider compacting this relation or increasing the
configuration parameter "max_fsm_pages".
NOTICE: number of page slots needed (309616) exceeds max_fsm_pages (153600)
HINT: Consider increasing the configuration parameter "max_fsm_pages"
to a value over 309616.
VACUUM
What does the warning indicate? How will it adversely affect the system.
Thanks.
-rs
--
It is all a matter of perspective. You choose your view by choosing
where to stand. --Larry Wall
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: max fsm pages question
2008-07-08 19:13 max fsm pages question Radhika S <radhika.sambamurti@gmail.com>
@ 2008-07-08 19:24 ` Bill Moran <wmoran@collaborativefusion.com>
2008-07-09 15:59 ` Re: max fsm pages question Vivek Khera <vivek@khera.org>
0 siblings, 1 reply; 4+ messages in thread
From: Bill Moran @ 2008-07-08 19:24 UTC (permalink / raw)
To: Radhika S <radhika.sambamurti@gmail.com>; +Cc: pgsql-performance
In response to "Radhika S" <radhika.sambamurti@gmail.com>:
>
> when i issued the vaccuum cmd, I recieved this message:
>
> echo "VACUUM --full -d ARSys" | psql -d dbname
>
> WARNING: relation "public.tradetbl" contains more than
> "max_fsm_pages" pages with useful free space
> HINT: Consider compacting this relation or increasing the
> configuration parameter "max_fsm_pages".
> NOTICE: number of page slots needed (309616) exceeds max_fsm_pages (153600)
> HINT: Consider increasing the configuration parameter "max_fsm_pages"
> to a value over 309616.
> VACUUM
>
> What does the warning indicate? How will it adversely affect the system.
It means any combination of the following things:
1) You're not vacuuming often enough
2) Your FSM settings are too low
3) You recently had some unusually high update/delete activity on that
table that's exceeded your normal settings for FSM and vacuum and
will need special attention to get back on track.
If you know it's #3, then just take steps to get things back on track
and don't worry about 1 or 2. If you don't think it's #3, then you
may want to increase the frequency of vacuum and/or increase the FSM
settings in your conf file.
You can do a CLUSTER to get that table back in shape, but be sure to
read up on CLUSTER so you understand the implications before you do so.
You can also temporarily raise the FSM settings to allow vacuum to work,
then lower them back down when it's under control again. This is one
of the few circumstances where you may want to VACUUM FULL.
If you don't handle this, that table will continue to grow in size on
the disk, taking up space unnecessarily and probably negatively
impacting performance.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
wmoran@collaborativefusion.com
Phone: 412-422-3463x4023
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: max fsm pages question
2008-07-08 19:13 max fsm pages question Radhika S <radhika.sambamurti@gmail.com>
2008-07-08 19:24 ` Re: max fsm pages question Bill Moran <wmoran@collaborativefusion.com>
@ 2008-07-09 15:59 ` Vivek Khera <vivek@khera.org>
0 siblings, 0 replies; 4+ messages in thread
From: Vivek Khera @ 2008-07-09 15:59 UTC (permalink / raw)
To: pgsql-performance
On Jul 8, 2008, at 3:24 PM, Bill Moran wrote:
> If you don't handle this, that table will continue to grow in size on
> the disk, taking up space unnecessarily and probably negatively
> impacting performance.
s/probably/definitely/
Also, if it was #3 on Bill's list, one thing to do is look for index
bloat. Reindex followed by vacuum might help as well.
As for running VACUUM FULL, I find it sometimes faster to just do a
dump + reload. A FULL vacuum is really, really, really, extremely,
slow.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2008-07-09 15:59 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-07-15 22:09 Re: max_fsm_pages question Josh Berkus <josh@agliodbs.com>
2008-07-08 19:13 max fsm pages question Radhika S <radhika.sambamurti@gmail.com>
2008-07-08 19:24 ` Re: max fsm pages question Bill Moran <wmoran@collaborativefusion.com>
2008-07-09 15:59 ` Re: max fsm pages question Vivek Khera <vivek@khera.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox