Re: Should I implement DROP INDEX CONCURRENTLY?

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Should I implement DROP INDEX CONCURRENTLY?
Дата
Msg-id CAMkU=1yqTy=zeegfoVfk8hZY7cWu-rt8ubixLCa=y+Hcy4djFg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should I implement DROP INDEX CONCURRENTLY?  (Simon Riggs <simon@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Gaetano Mendola
Дата:
Сообщение: Re: CUDA Sorting
Следующее
От: Joshua Berkus
Дата:
Сообщение: 3rd Cluster Hackers Summit, May 15th in Ottawa