Re: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Дата
Msg-id CAMkU=1xpfQRcFPx3x++KVxQ7FQO=6MYERPS22Fh5ekJztmfytA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)  (Jim Nasby <jim@nasby.net>)
Список pgsql-hackers
On Sat, Jan 21, 2012 at 2:29 PM, Jim Nasby <jim@nasby.net> wrote:
> On Jan 20, 2012, at 11:54 AM, Heikki Linnakangas wrote:

>> 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
tablesbeing 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'sprobably more work... 

If the head and tail are both protected by BufFreelistLock, I'm pretty
sure this will make things worse, not better.

If we change to having head and tail protected by separate spinlocks,
then I don't see how you can remove the last buffer from the list, or
add a buffer to an empty list, without causing havoc.

Does anyone have ideas for implementing a cross-platform, lock-free,
FIFO linked list?  Without that, I don't see how we are going to get
anywhere on this approach.

Cheers,

Jeff


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Inline Extension
Следующее
От: Robert Treat
Дата:
Сообщение: Re: Page Checksums