"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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
