"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
