Re: Should I implement DROP INDEX CONCURRENTLY? - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Should I implement DROP INDEX CONCURRENTLY?
Date
Msg-id FBB4EDF8-2CEB-48B3-8F99-A87352A87847@nasby.net
Whole thread Raw
In response to Re: Should I implement DROP INDEX CONCURRENTLY?  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Should I implement DROP INDEX CONCURRENTLY?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.
>
> On top of that, taking what Robert Haas mentioned on another thread,
> InvalidateBuffer currently calls StretegyFreeBuffer(), which waits for
> an ExclusiveLock on the BufFreelistLock. On a busy system this will be
> heavily contended, so adding blocks to the freelist only if the lock
> is free seems warranted.

Couldn't we just leave the buffers alone? Once an index is dropped and that's pushed out through the catalog then
nothingshould be trying to access them and they'll eventually just get aged out. 

In fact, IIRC the function that scans for buffers actually checks to see if a rel still exists before it returns the
buffer...
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: 16-bit page checksums for 9.2
Next
From: Brad Davis
Date:
Subject: Re: [patch] Improve documentation around FreeBSD Kernel Tuning