Re: PostgreSQL 18 Beta 1 release announcement draft

On Mon, May 5, 2025 at 3:07 PM Jonathan S. Katz <jkatz(at)postgresql(dot)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