On Friday May 7 2004 12:48, Tom Lane wrote: > "Ed L." <pgsql@bluepolka.net> writes: > > 2) Would this low setting of 10000 explain the behavior we saw of > > seqscans of a perfectly analyzed table with 1000 rows requiring > > ridiculous amounts of time even after we cutoff the I/O load? > > Possibly. The undersized setting would cause leakage of disk space > (that is, new rows get appended to the end of the table even when space > is available within the table, because the system has "forgotten" about > that space due to lack of FSM slots to remember it in). If the physical > size of the table file gets large enough, seqscans will take a long time > no matter how few live rows there are. I don't recall now whether your > VACUUM VERBOSE results showed that the physical table size (number of > pages) was out of proportion to the actual number of live rows. But it > sure sounds like that might have been the problem. If it were indeed the case that we'd leaked a lot of diskspace, then after bumping max_fsm_pages up to a much higher number (4M), will these pages gradually be "remembered" as they are accessed by autovac and or queried, etc? Or is a dump/reload or 'vacuum full' the only way? Trying to avoid downtime... ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
