Re: Lock problem with autovacuum truncating heap

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
smalltruncations are likely to be more common than big ones. 

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
pointand scan forward from there.  Or whatever we think the right chunk size is to get some benefit from kernel
readaheadwithout making the "truncate 1 block" case slow. 

...Robert