| От | Tom Lane |
|---|---|
| Тема | Re: Analyse - max_locks_per_transaction - why? |
| Дата | |
| Msg-id | 14022.1100108789@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Analyse - max_locks_per_transaction - why? (Phil Endecott <spam_from_postgresql_general@chezphil.org>) |
| Ответы |
Re: Analyse - max_locks_per_transaction - why?
|
| Список | pgsql-general |
Phil Endecott <spam_from_postgresql_general@chezphil.org> writes:
> Naively I imagined that ANALYSE looks at each table in turn,
> independently. So why does it need more locks when there are more
> tables?
7.4 runs a database-wide ANALYZE as a single transaction, so the locks
accumulate. This was recognized to be a bad idea :-(. 8.0 is a bit
smarter.
The best bet in 7.4 is probably to use VACUUM ANALYZE rather than
analyzing separately. That will force it to use a transaction per
table.
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера