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

From Jeff Janes
Subject Re: Should I implement DROP INDEX CONCURRENTLY?
Date
Msg-id CAMkU=1yqTy=zeegfoVfk8hZY7cWu-rt8ubixLCa=y+Hcy4djFg@mail.gmail.com
Whole thread Raw
In response to Re: Should I implement DROP INDEX CONCURRENTLY?  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Sun, Jan 8, 2012 at 8:19 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, Jan 4, 2012 at 11:14 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
>> 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.
>
> v2 attached with cleanup of some random stuff that crept onto patch.

Hi Simon,

Based on the way this patch leaves the old code behind (using #ifdef),
this looks more like a WIP patch which you want people to do
performance testing with, rather than  patch proposed for committing.
If that is the case, could you outline the type of performance testing
where you think it would make a difference (and whether it should be
done on top of the main patch from this thread, the concurrent index
drop one)?

Also, it would be much easier to do the performance testing if this
behavior was controlled by a temporarily added GUC, rather than an
#ifdef.  Do you think it is feasible to do that, or would the overhead
of a single "if (some_guc)" per StrategyGetBuffer and
StrategyFreeBuffer call distort things too much?

Cheers,

Jeff


pgsql-hackers by date:

Previous
From: Gaetano Mendola
Date:
Subject: Re: CUDA Sorting
Next
From: Joshua Berkus
Date:
Subject: 3rd Cluster Hackers Summit, May 15th in Ottawa