Re: Should I implement DROP INDEX CONCURRENTLY?

Jim Nasby <jim(at)nasby(dot)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. Simon is after a different solution involving getting
rid of the clock sweep, but he has failed to explain how that's not
going to end up being the same type of contention-prone coding that we
got rid of by adopting the clock sweep, some years ago. Yeah, the sweep
takes a lot of spinlocks, but that only matters if there is contention
for them, and the sweep approach avoids the need for a centralized data
structure.

(BTW, do we have a separate clock sweep hand for each backend? If not,
there might be some low hanging fruit there.)

regards, tom lane