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
