Re: Best practice - Vacuum. Replication suggestions and pg vs mysql
В списке pgsql-admin по дате отправления:
| От | Ron Mayer |
|---|---|
| Тема | Re: Best practice - Vacuum. Replication suggestions and pg vs mysql |
| Дата | |
| Msg-id | d1dsv0$q0v$1@news.hub.org обсуждение исходный текст |
| Ответ на | Re: Best practice - Vacuum. Replication suggestions and pg vs mysql question (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Best practice - Vacuum. Replication suggestions and pg vs mysql
|
| Список | pgsql-admin |
Tom Lane wrote:
> David B <davidb999@gmail.com> writes:
>>15minute lock is a long time.
> There's no lock, unless you are using VACUUM FULL which you shouldn't.
Or, I believe, if he has any GIST indexes (such as tsearch or
postgis ones). At least it seems normal vacuum locks GIST indexes
for quite some time here.
I ended up stopping using vacuum_cost_delay to minimize the
time those GIST indexes seemed locked.
Ron
PS: If I'm right, I wonder if VACUUM or at least autovacuum
should automatically force vacuum_cost_delay to zero while
holding locks (i.e. while doing GIST indexes) to reduce the
time those locks are held.
В списке pgsql-admin по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера