Re: Resumable vacuum proposal and design overview

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Wed, 2007-02-28 at 13:53 +0900, Galy Lee wrote:
>> In the current implementation of concurrent vacuum, the third is not
>> satisfied obviously, the first issue comes to my mind is the
>> lazy_truncate_heap, it takes AccessExclusiveLock for a long time,
>> that is problematic.

> Are you saying you know for certain this lock is held for a long time,
> or are you just saying you think it is? If you have some evidence for
> long truncation times then that would be a separate issue of concern,
> since that might starve out normal users. Please say more?

lazy_truncate_heap does a ConditionalLockAcquire, that is, it won't
succeed in acquiring the exclusive lock if there is any competition.
And I find it hard to believe that it will hold the lock very long
if it does get it --- in most scenarios it won't be possible to remove
very many pages, so the scan won't take long. (Of course that is
arguably a bug, but until you can fix things so that an average VACUUM
*can* remove a lot of pages, it's hardly profitable to worry about
whether this step creates a concurrency problem.)

So I agree with Simon: if you want us to believe there's a performance
issue here, please present some evidence.

regards, tom lane