Re: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?) - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Date
Msg-id CAMkU=1xpfQRcFPx3x++KVxQ7FQO=6MYERPS22Fh5ekJztmfytA@mail.gmail.com
Whole thread Raw
In response to Re: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)  (Jim Nasby <jim@nasby.net>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Inline Extension
Next
From: Robert Treat
Date:
Subject: Re: Page Checksums