On Thu, Jul 16, 2015 at 10:17 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Jul 16, 2015 at 11:21 AM, Haribabu Kommi <kommi.harib...@gmail.com> > wrote: > >> >> Here I attached updated patches, >> 1) without prefetch logic. >> 2) with combined vm and prefetch logic. >> > > I think it is better to just get the first patch in as that in itself is a > clear win and then we can evaluate the second one (prefetching during > truncation) separately. I think after first patch, the use case for doing > prefetch seems to be less beneficial and I think it could hurt by loading > not required pages (assume you have prefetched 32 pages and after > inspecting first page, it decides to quit the loop as that is non-empty page > and other is when it has prefetched just because for page the visibility map > bit was cleared, but for others it is set) in OS buffer cache.
Yes, in the above cases, the prefetch is an overhead. I am not sure how frequently such scenarios occur in real time scenarios. > Having said that, I am not against prefetching in this scenario as that > can help in more cases then it could hurt, but I think it will be better > to evaluate that separately. Yes, the prefetch patch works better in cases, where majorly the first vacuum skips the truncation because of lock waiters. If such cases are more in real time scenarios, then the prefetch patch is needed. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
