Re: VACUUM ANALYZE blocking both reads and writes to a table
От | Tom Lane |
---|---|
Тема | Re: VACUUM ANALYZE blocking both reads and writes to a table |
Дата | |
Msg-id | 3064.1214852440@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: VACUUM ANALYZE blocking both reads and writes to a table (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: VACUUM ANALYZE blocking both reads and writes to a
table
|
Список | pgsql-performance |
Alvaro Herrera <alvherre@commandprompt.com> writes: > Peter Schuller wrote: >> Even with the fix the lock is held. Is the operation expected to be >> "fast" (for some definition of "fast") and in-memory, or is this >> something that causes significant disk I/O and/or scales badly with >> table size or similar? > It is fast. Well, it's *normally* fast. In a situation where there are a whole lot of empty pages at the end of the table, it could be slow. That's probably not very likely on a heavily used table. One should also note that (1) The only way vacuum will be able to obtain an exclusive lock in the first place is if there are *no* other transactions using the table at the time. (2) If it's autovacuum we're talking about, it will get kicked off the table if anyone else comes along and wants a conflicting lock. regards, tom lane
В списке pgsql-performance по дате отправления: