Re: Faster inserts with mostly-monotonically increasing values - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Faster inserts with mostly-monotonically increasing values
Date
Msg-id CAH2-Wzkj4RMs3NSha1oKOg7+vdDb6Lc-wZUGheJP7foNNcwV+g@mail.gmail.com
Whole thread Raw
In response to Re: Faster inserts with mostly-monotonically increasing values  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: Faster inserts with mostly-monotonically increasing values  (Claudio Freire <klaussfreire@gmail.com>)
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: constraint exclusion and nulls in IN (..) clause
Next
From: Yura Sokolov
Date:
Subject: Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian abit)