On Mon, May 5, 2025 at 3:07 PM Jonathan S. Katz <jk...@postgresql.org> wrote: > > Hi, > > Attached is a draft of the PostgreSQL 18 Beta 1 release announcement. > The goal of this announcement is to introduce the new capabilities > planned for PostgreSQL 18 and give users an idea of areas we'd like to > see tested. > > Please check for accuracy and if there are glaring omissions (happy to > have the discussion on what to include in here, though note it's not > possible to list everything in here). If a description is unclear or > there are typos, I'm also happy to modify it; that said, for these > suggestions I'm looking for recommendations that bring better clarity to > a description vs. nitpicking over phrasing.
One small piece of feedback on this: "PostgreSQL 18 adds support for using "skip scan" lookups on multicolumn B-tree indexes, which can result in faster execution times for queries with multiple conditions." I don't think that this is quite right; there doesn't have to be multiple conditions involved in the query (though it *is* true that skip scan can only be used with a multicolumn B-tree index). The typical skip scan involves a query whose predicate has only a single "=" condition, which is on the second column from a multicolumn index. Typically, the first index column won't appear in the query predicate at all -- it is wholly omitted, and yet the index can be scanned reasonably efficiently when there aren't too many distinct values in the leading/skipped column. (Of course it can be a lot more complicated than this, but I'm just talking about the typical, simple case.) I suggest something closer to: "PostgreSQL 18 adds support for using "skip scan" lookups on multicolumn B-tree indexes, which can result in faster execution times for queries that omit a "=" condition on one or more prefix index columns." There's a real danger in users confusing skip scan for loose index scan, which is actually quite a different feature. Many hackers have made the same mistake in the past. ISTM that specifically describing how the feature applies to queries that omit an "=" condition makes this misunderstanding less likely to occur. -- Peter Geoghegan
