public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Peter Geoghegan <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: PG 18 release notes draft committed
Date: Thu, 22 May 2025 22:24:51 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAH2-Wz=2CWXgO1+uyR-VfN3ALMtFnfTtXK-VtkoQQ89ogm=4sg@mail.gmail.com>
References: <[email protected]>
<CAH2-Wz=2CWXgO1+uyR-VfN3ALMtFnfTtXK-VtkoQQ89ogm=4sg@mail.gmail.com>
On Wed, May 21, 2025 at 05:57:07PM -0400, Peter Geoghegan wrote:
> On Thu, May 1, 2025 at 10:44 PM Bruce Momjian <[email protected]> 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 <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
Attachments:
[text/x-diff] master.diff (499B, ../[email protected]/2-master.diff)
download | inline diff:
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>
view thread (147+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: PG 18 release notes draft committed
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox