On Friday 21 Mar 2003 4:31 am, Florian Weimer wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > You definitely need to increase the fsm shared memory parameters. The
> > default max_fsm_relations is just plain too small (try 1000) and the
> > default_max_fsm_pages is really only enough for perhaps a 100Mb
> > database. I'd try bumping it to 100,000. Note you need a postmaster
> > restart to make these changes take effect.
>
> Hmm, are there any guidelines for choosing these values?
>
> We have a database with a table into which we insert about 4,000,000
> rows each day, and delete another 4,000,000 rows. The total row count
> is around 40 million, I guess, and the rows are about 150 bytes long.
> (VACUUM FULL is running at the moment, so I can't check.)
I suggest you split your tables into exactly similar tables using inheritance.
Your queries won't be affected as you can make them on parent table and get
same result.
But as far as vacuuming goes, you can probably dump a child table entirely and
recreate it as a fast alternative to vacuum.
Only catch is, I don't know if inherited tables would use their respective
indxes other wise your queries might be slow as anything.
> One of the columns is time-based and indexed, so we suffer from the
> creeping index syndrome. A nightly index rebuild followed by a VACUUM
> ANALYZE isn't a problem (it takes less than six ours), but this
> doesn't seem to be enough (we seem to lose disk space nevertheless).
I am sure a select * from table into another table; drop table; renamre temp
table kind of hack would be faster than vacuuming in this case..
This is just a suggestion. Good if this works for you..
Shridhar