On Mar 26, 2011, at 1:44 PM, Itagaki Takahiro <[email protected]> wrote: > On Sun, Mar 27, 2011 at 01:12, Simon Riggs <[email protected]> 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 -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
