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

On Tue, Apr 10, 2018 at 1:18 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:

> 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.
>
>
Hmm. I am a bit confused why we want to mention anything about something
we're not even considering seriously, let alone any patch or work in that
direction. If we at all change everything to use extent based storage,
there would be many other things that will break and require changes, no?

Apart from that, other changes requested are included in the patch. This
also takes care of Heikki's observation regarding UNLOGGED tables on the
other thread.

Thanks,
Pavan

--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services