Re: Concurrent VACUUM and ANALYZE
От | Tom Lane |
---|---|
Тема | Re: Concurrent VACUUM and ANALYZE |
Дата | |
Msg-id | 19487.1216684741@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Concurrent VACUUM and ANALYZE ("Jonah H. Harris" <jonah.harris@gmail.com>) |
Ответы |
Re: Concurrent VACUUM and ANALYZE
|
Список | pgsql-hackers |
"Jonah H. Harris" <jonah.harris@gmail.com> writes: > Because we wouldn't want multiple ANALYZEs running on the same table, > changing the lock back to an AccessShareLock doesn't sound like a > solution. It flat will not work. We used to do it that way, and it didn't (search for "tuple concurrently updated" in the archives). > However, what are the thoughts around creating another, > more-specific lock? Perhaps something like ShareUpdateAnalysisLock? The general overhead involved in a whole new lock type is high enough that I would resist taking this path. (It's certainly a lot more than adding an entry to one enum someplace --- offhand I can name docs and grammar as important issues. And no you don't get to have a hidden lock type that no one can see.) Also, as Alvaro points out, it's far from clear that concurrent VACUUM and ANALYZE is as safe as you think --- they both want to write the same fields in pg_class. regards, tom lane
В списке pgsql-hackers по дате отправления: