On Thursday, November 12, 2020 1:14 PM, Tsunakawa-san wrote: > The patch looks OK. I think as Thomas-san suggested, we can remove the > modification to smgrnblocks() and don't care wheter the size is cached or not. > But I think the current patch is good too, so I'd like to leave it up to a > committer to decide which to choose. > I measured performance in a different angle -- the time > DropRelFileNodeBuffers() and DropRelFileNodeAllBuffers() took. That > reveals the direct improvement and degradation. > > I used 1,000 tables, each of which is 1 MB. I used shared_buffers = 128 MB > for the case where the traditional full buffer scan is done, and > shared_buffers > = 100 GB for the case where the optimization path takes effect. > > The results are almost good as follows: > > A. UNPATCHED > > 128 MB shared_buffers > 1. VACUUM = 0.04 seconds > 2. TRUNCATE = 0.04 seconds > > 100 GB shared_buffers > 3. VACUUM = 69.4 seconds > 4. TRUNCATE = 69.1 seconds > > > B. PATCHED > > 128 MB shared_buffers (full scan) > 5. VACUUM = 0.04 seconds > 6. TRUNCATE = 0.07 seconds > > 100 GB shared_buffers (optimized path) > 7. VACUUM = 0.02 seconds > 8. TRUNCATE = 0.08 seconds > > > So, I'd like to mark this as ready for committer. I forgot to reply. Thank you very much Tsunakawa-san for testing and to everyone who has provided their reviews and insights as well.
Now thinking about smgrnblocks(), currently Thomas Munro is also working on implementing a shared SmgrRelation [1] to store sizes. However, since that is still under development and the discussion is still ongoing, I hope we can first commit these set of patches here as these are already in committable form. I think it's alright to accept the early improvements implemented in this thread to the source code. [1] https://www.postgresql.org/message-id/CA%2BhUKG%2B7Ok26MHiFWVEiAy2UMgHkrCieycQ1eFdA%3Dt2JTfUgwA%40mail.gmail.com Regards, Kirk Jamison
