On Tue, Mar 9, 2010 at 8:27 AM, Vidhya Bondre <meetvbondre@xxxxxxxxx> wrote: >> >> are you using the same postgresql.conf? have you created more >> partitions? using advisory locks? > > Yes we are using same conf files. In a week we create around 5 partitions. > We are not using advisory locks >> >> In any event, increase the max_locks_per_transaction setting and >> restart the database. > > > Currently the value of max_locks_per_transaction is 64 modifying it to 96 > works. > Have a couple of questions > 1] As and when we add partitions will we have to increase this parameter ? > 2] will we have to consider any othe parameter twick while increasing this > one? If you are doing 'in transaction' operations that involve a lot of tables this figure has to be bumped, sometimes significantly. You might be tempted just crank it, and be done with this problem. If so, be advised of what happens when you do: *) more shared memory usage (make sure you have memory and shared_buffers is appropriately set). however for what you get the usage is relatively modest. *) anything that scans the entire in memory lock table takes longer in relationship to this .conf value. AFAIK, the only noteworthy thing that does this is the pg_locks view. The 'other' big shared memory tradeoff you historically had to deal with, the fsm map, is gone in 8.4. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
