| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
| Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(dot)riggs(at)2ndquadrant(dot)com> |
| Subject: | Re: Faster inserts with mostly-monotonically increasing values |
| Date: | 2018-03-06 04:45:00 |
| Message-ID: | CAH2-Wzkj4RMs3NSha1oKOg7+vdDb6Lc-wZUGheJP7foNNcwV+g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 5, 2018 at 7:10 PM, Claudio Freire <klaussfreire(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yura Sokolov | 2018-03-06 05:23:57 | Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit) |
| Previous Message | Amit Langote | 2018-03-06 04:43:11 | Re: constraint exclusion and nulls in IN (..) clause |