Re: Lock problem with autovacuum truncating heap

On 3/26/2011 3:17 PM, Robert Haas wrote:
> On Mar 26, 2011, at 1:44 PM, Itagaki Takahiro<itagaki.takahiro@gmail.com>  wrote:
>>  On Sun, Mar 27, 2011 at 01:12, Simon Riggs<simon@2ndquadrant.com>  wrote:
>>>>  At the same time I would
>>>>  change count_nondeletable_pages() so that it uses a forward scan direction
>>>>  (if that leads to a speedup).
>>
>>  +1.
>
> Hmm.  That would speed up truncations that are large relative to the table size, but slow down small truncations.  And small truncations are likely to be more common than big ones.

For small truncations the blocks to check are most likely found in 
memory (shared or OS buffer) anyway, in which case the access pattern 
should be rather irrelevant.

>
> Maybe we could do a mix... back up 16MB and scan forward; if all those pages are empty then back up 16MB from the start point and scan forward from there.  Or whatever we think the right chunk size is to get some benefit from kernel readahead without making the "truncate 1 block" case slow.

That was what I meant. Go in steps of 16-64MB backwards and scan from 
there to the current end in forward direction to find a nondeletable 
block. In between these steps, release and reacquire the exclusive lock 
so that client transactions can get their work done.


Jan

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