Re: Should I implement DROP INDEX CONCURRENTLY?
От | Tom Lane |
---|---|
Тема | Re: Should I implement DROP INDEX CONCURRENTLY? |
Дата | |
Msg-id | 29638.1325635895@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Should I implement DROP INDEX CONCURRENTLY? (Jim Nasby <jim@nasby.net>) |
Ответы |
Re: Should I implement DROP INDEX CONCURRENTLY?
|
Список | pgsql-hackers |
Jim Nasby <jim@nasby.net> writes: > Yeah, but the problem we run into is that with every backend trying to run the clock on it's own we end up with high contentionagain... it's just in a different place than when we had a true LRU. The clock sweep might be cheaper than thelinked list was, but it's still awfully expensive. I believe our best bet is to have a free list that is actually usefulin normal operations, and then optimize the cost of pulling buffers out of that list as much as possible (and let thebgwriter deal with keeping enough pages in that list to satisfy demand). Well, maybe, but I think the historical evidence suggests that that approach will be a loser, simply because no matter how cheap, the freelist will remain a centralized and heavily contended data structure. IMO we need to be looking for a mechanism that has no single point of contention, and modifying the clock sweep rules looks like the best way to get there. Still, he who wants to do the work can try whatever approach he feels like. regards, tom lane
В списке pgsql-hackers по дате отправления: