Re: pgsql: Optimize btree insertions for common case of increasing values

On Thu, Apr 5, 2018 at 10:16 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I think you can take that wording almost verbatim. Obviously it should
> refer to the optimization by name, and blend into the surrounding text
> in the README. I suggest putting a small section before "On-the-Fly
> Deletion Of Index Tuples", but after the main discussion of deletion +
> recycling. It's essentially an exception to the general rule, so that
> placement makes sense to me.

I also think that we should also say something about extent-based
storage. This optimization relies on the assumption that reading some
stale block cannot read a block from some other relation (which could
perhaps be its own rightmost leaf page). If we ever wanted to share
storage between small relations as extents, that would invalidate the
optimization.

This came up recently on the "PostgreSQL's handling of fsync() errors
is unsafe and risks data loss at least on XFS" thread, and what I
describe is in fact how other database systems manage storage, so this
seems like a real practical consideration.

--
Peter Geoghegan