Re: Lock problem with autovacuum truncating heap

On 3/26/2011 12:12 PM, Simon Riggs wrote:
> On Sat, Mar 26, 2011 at 2:30 PM, Jan Wieck<JanWieck(at)yahoo(dot)com> wrote:
>
>> My current idea for a fix is to modify lazy_truncate_heap(). It does acquire
>> and release the exclusive lock, so it should be possible to do this in
>> smaller chunks, releasing and reacquiring the lock so that client
>> transactions can get their work done as well.
>
> Agreed, presumably with vacuum delay in there as well?

Not sure about that. My theory is that unless somebody needs access to
that table, just have at it like it is now.

The current implementation seems to assume that the blocks, checked for
being empty, are still found in memory (vacuum just scanned them). And
that seems to be correct most of the time, in which case adding vacuum
delay only gives more time that the blocks get evicted and have to be
read back in.

>
>> At the same time I would
>> change count_nondeletable_pages() so that it uses a forward scan direction
>> (if that leads to a speedup).
>
> Do we need that? Linux readahead works in both directions doesn't it?
> Guess it wouldn't hurt too much.
>
> BTW does it read the blocks at that point using a buffer strategy?

Is reading a file backwards "in 8K blocks" actually an access pattern,
that may confuse buffer strategies?

I don't know. I also don't know if what I am suggesting is much better.
If you think about it, I merely suggested to "try" and do the same
access pattern with larger chunks. We need to run some tests to find out.

Jan

--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin