On Tue, Apr 10, 2018 at 1:18 AM, Peter Geoghegan <pg@bowt.ie> wrote:
On Thu, Apr 5, 2018 at 10:16 AM, Peter Geoghegan <pg@bowt.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.
