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 по дате отправления: