Re: Best practice - Vacuum. Replication suggestions and pg vs mysql

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Best practice - Vacuum. Replication suggestions and pg vs mysql
Дата
Msg-id 3780.1111129454@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Best practice - Vacuum. Replication suggestions and pg vs mysql  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Список pgsql-admin
Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Tom Lane wrote:
>> 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.

Good point --- gist (and rtree) indexes still don't have any support for
concurrent updates, so they have to be locked while VACUUM scans them.

> 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.

Perhaps.  VACUUM going at full tilt would cause a system-wide
performance impact, though, while the lock only affects processes
trying to use or update that index.  So you could argue it either
way.

The best solution would be to fix GIST ;-)

            regards, tom lane

В списке pgsql-admin по дате отправления:

Предыдущее
От: Ron Mayer
Дата:
Сообщение: Re: Best practice - Vacuum. Replication suggestions and pg vs mysql
Следующее
От: Uwe Maiwald
Дата:
Сообщение: large database versus many databases