Re: Analyse - max_locks_per_transaction - why?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Analyse - max_locks_per_transaction - why?
Дата
Msg-id 10436.1100200474@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Analyse - max_locks_per_transaction - why?  (Phil Endecott <spam_from_postgresql_general@chezphil.org>)
Список pgsql-general
Phil Endecott <spam_from_postgresql_general@chezphil.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

В списке pgsql-general по дате отправления:

Предыдущее
От: Doug McNaught
Дата:
Сообщение: Re: DROP DATABASE, but still there
Следующее
От: Geoffrey
Дата:
Сообщение: oid size on 64 bit machine