On Jan 20, 2012, at 11:54 AM, Heikki Linnakangas wrote: > On 04.01.2012 13:14, Simon Riggs wrote: >> On Tue, Jan 3, 2012 at 11:28 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: >>> Jim Nasby<j...@nasby.net> writes: >>>> On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote: >>>>> This could well be related to the fact that DropRelFileNodeBuffers() >>>>> does a scan of shared_buffers, which is an O(N) approach no matter the >>>>> size of the index. >>> >>>> Couldn't we just leave the buffers alone? Once an index is dropped and >>>> that's pushed out through the catalog then nothing should be trying to >>>> access them and they'll eventually just get aged out. >>> >>> No, we can't, because if they're still dirty then the bgwriter would >>> first try to write them to the no-longer-existing storage file. It's >>> important that we kill the buffers immediately during relation drop. >>> >>> I'm still thinking that it might be sufficient to mark the buffers >>> invalid and let the clock sweep find them, thereby eliminating the need >>> for a freelist. >> >> My patch puts things on the freelist only when it is free to do so. >> Not having a freelist at all is probably a simpler way of avoiding the >> lock contention, so I'll happily back that suggestion instead. Patch >> attached, previous patch revoked. > > So, you're proposing that we remove freelist altogether? Sounds reasonable, > but that needs to be performance tested somehow. I'm not sure what exactly > the test should look like, but it probably should involve an OLTP workload, > and large tables being created, populated to fill the cache with pages from > the table, and dropped, while the OLTP workload is running. I'd imagine that > the worst case scenario looks something like that.
We should also look at having the freelist do something useful, instead of just dropping it completely. Unfortunately that's probably more work... -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
