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 по дате отправления: