Re: Block level concurrency during recovery

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Block level concurrency during recovery
Дата
Msg-id 4900A49C.1060602@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Block level concurrency during recovery  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Block level concurrency during recovery  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Simon Riggs wrote:
> It would also be possible to introduce a special tweak there which is
> that if the block is not in cache, don't read it in at all. If its not
> in cache we know that nobody has a pin on it, so don't need to read it
> in just to say "got the lock". That icing for later.

Heh, that's clever :-). We could actually use a method like that to 
solve the whole problem. After the (replay of the) b-tree vacuum is 
finished, scan through all shared buffers, and get a vacuum lock on 
every page of that index that's in cache. Groveling through all shared 
buffers would be slower for small indexes, though.

I believe the "vacuum lock every leaf page" behavior is only needed for 
system catalogs. You have other issues with those still, namely that 
table locks are not yet taken appropriately, so I'm not sure if this is 
worth worrying about until that's done.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Regression in IN( field, field, field ) performance
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Re: Unicode escapes in literals