Re: Faster inserts with mostly-monotonically increasing values

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Faster inserts with mostly-monotonically increasing values
Дата
Msg-id CAH2-Wzkj4RMs3NSha1oKOg7+vdDb6Lc-wZUGheJP7foNNcwV+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Faster inserts with mostly-monotonically increasing values  (Claudio Freire <klaussfreire@gmail.com>)
Ответы Re: Faster inserts with mostly-monotonically increasing values  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-hackers
On Mon, Mar 5, 2018 at 7:10 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
>> Introducing any case that allows us to land on a recycled page, and
>> reason that it must at least not be the page we were looking for based
>> on *any* criteria about the page itself seems very brittle. Yeah, it
>> probably won't break in practice, but it's a bad design.
>
> How is this any different from btvacuumscan?
>
> I don't think it can be argued that somehow btvacuumscan has
> permission to be brittle and the rest of the code doesn't.

VACUUM doesn't have to worry about concurrent page recycling because
it is already the only thing that performs page deletion. It's already
the process that has the exclusive right to give index pages back to
the FSM.

-- 
Peter Geoghegan


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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: constraint exclusion and nulls in IN (..) clause
Следующее
От: Yura Sokolov
Дата:
Сообщение: Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian abit)