From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Analyse - max_locks_per_transaction - why? |
Date: | 2004-11-11 19:14:34 |
Message-ID: | 10436.1100200474@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> writes:
> Thanks Tom. I will upgrade to 8.0 one day but not soon. In the
> meantime, is there a way to judge a suficient setting for
> max_locks_per_transaction so that a global ANALYZE will work? It
> doesn't seem to be one lock per table or anything as simple as that.
No. The shared lock table has room for max_locks_per_transaction *
max_connections entries (actually rather more, but that's the supported
limit), so as soon as this exceeds the number of tables in your DB
the ANALYZE will work ... at least as long as nothing else is going on.
Any other transactions you may be running will eat some lock entries,
and you have to allow for those.
The conservative answer is to set max_locks_per_transaction to
(tables in database)/max_connections more than you were using before.
This is still probably overkill, since for most purposes the default
value is plenty.
There was some discussion recently of renaming the
max_locks_per_transaction variable to make it clearer that it's not
a hard per-transaction limit but a global average. Nobody really
came up with a better name though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Geoffrey | 2004-11-11 19:17:29 | oid size on 64 bit machine |
Previous Message | Doug McNaught | 2004-11-11 19:03:18 | Re: DROP DATABASE, but still there |