Philip Warner <[EMAIL PROTECTED]> writes: > We have a frequently updated (peak > 5/sec) table with about 1000 rows. > We run VACCUM FULL on this table every 5 minutes.
Plain vacuum (perhaps executed even more often, like once a minute) will cause fewer locking headaches.
We have done both in the past, but found some tables still just grew (perhaps just because of infrequent locks that prevented the plain VACUUM). I'll go back to the plain VACUUM and monitor the table growth.
Am I correct in saying that the FSM now tracks the entire table, and that the FSM parameters just determine how much is stored in memory?
I think you could do that by setting a statement timeout.
This would be a good solution if we still see growth with plain VACUUM.
Is any type of opportunistic locking likely/planned for a future version (ie. a has lock, b asks for conflicting lock, c asks for lock that is OK with a but denied by b; so c's lock is allowed and b stays waiting).
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp.mit.edu:11371 |/
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
