Re: Lock problem with autovacuum truncating heap

On Mar 26, 2011, at 1:44 PM, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Sun, Mar 27, 2011 at 01:12, Simon Riggs <simon(at)2ndquadrant(dot)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.

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.

...Robert