Jan Peterson <[EMAIL PROTECTED]> writes:
> Based on this, it looks like we could stand to bump up our FSM another
> couple hundred thousand. Does it buy us anything to reduce the number
> of FSM relations from the default of 1000?
Not a lot; as the comment says, those slots are only about 50 byte
Thomas F. O'Connell:
>Do you have your Free Space Map settings configured appropriately?
Our current FSM settings are:
max_fsm_pages = 50 # min max_fsm_relations*16, 6 bytes each
max_fsm_relations = 1000# min 100, ~50 bytes each
> You'll want to run a VACUUM VERBOSE and note
Jan Peterson <[EMAIL PROTECTED]> writes:
> We have been experiencing poor performance of VACUUM in our production
> database.
Which PG version, exactly?
> Everything works great until our rolling delete kicks in. Of course,
> we are doing periodic VACUUMS on all tables, with frequent VACUUMs on
On Sep 4, 2005, at 1:16 AM, Jan Peterson wrote:
Hello,
We have been experiencing poor performance of VACUUM in our production
database. Relevant details of our implementation are as follows:
1. We have a database that grows to about 100GB.
2. The database is a mixture of large and small ta
Hello,
We have been experiencing poor performance of VACUUM in our production
database. Relevant details of our implementation are as follows:
1. We have a database that grows to about 100GB.
2. The database is a mixture of large and small tables.
3. Bulk data (stored primarily in pg_largeobj
