On Wed, May 21, 2025 at 05:57:07PM -0400, Peter Geoghegan wrote: > On Thu, May 1, 2025 at 10:44 PM Bruce Momjian <br...@momjian.us> wrote: > > I have committd the first draft of the PG 18 release notes. > > I suggest that you use something like the following wording for the > skip scan feature: > > Add the "skip scan" optimization, which enables more efficient scans > of multicolumn B-tree indexes for queries that omit an "=" condition > on one or more prefix index columns. > > This is similar to the wording that appeared in the beta1 announcement. > > The term "skip scan" has significant baggage -- we need to be careful > to not add to the confusion. There are naming conflicts, which seem > likely to confuse some users. Various community members have in the > past referred to a feature that MySQL calls loose index scan as skip > scan, which seems wrong to me -- it clashes with the naming > conventions used by other RDBMSs, for no good reason. Skip scan and > loose index scan are in fact rather different features. > > For example, TimescaleDB offers Loose index scan as part of the > TimescaleDB Postgres extension, which (for whatever reason) they chose > to call skip scan: > > https://www.timescale.com/blog/how-we-made-distinct-queries-up-to-8000x-faster-on-postgresql > > Note that loose index scan can only be used with certain kinds of > queries involving DISTINCT or GROUP BY. Whereas skip scan (in Oracle > and now in Postgres) can work with any query that omits one or more > "=" conditions on a prefix index column from a multicolumn index (when > a later index column has some condition that can be used by the scan) > -- it doesn't have to involve aggregation. I believe that describing > the feature along these lines will make it less likely that users will > be confused by the apparent naming conflict. > > FWIW, I don't think that it's important that the release notes point > out that skip scan is only helpful when the leading/skipped column is > low cardinality (though that detail is accurate).
I see your point that we are not defining what this does. I went with the attached text. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml index 2a52cef1c7c..a2b1921fbbb 100644 --- a/doc/src/sgml/release-18.sgml +++ b/doc/src/sgml/release-18.sgml @@ -469,7 +469,8 @@ Allow skip scans of btree indexes (Peter Geoghegan) </para> <para> -This is effective if the earlier non-referenced columns contain few unique values. +This allows muti-column btree indexes to be used by queries that only +reference the second or later indexed columns. </para> </listitem>
