Date: Thu, 22 May 2025 22:31:29 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Subject: Re: PG 18 release notes draft committed
Message-ID: <aC_eAbQ3RVdDx0zp@momjian.us>
References: <aBQxop9YxQDad8-W@momjian.us>
 <CAH2-Wz=2CWXgO1+uyR-VfN3ALMtFnfTtXK-VtkoQQ89ogm=4sg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAH2-Wz=2CWXgO1+uyR-VfN3ALMtFnfTtXK-VtkoQQ89ogm=4sg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aC_eAbQ3RVdDx0zp%40momjian.us>
Precedence: bulk

On Wed, May 21, 2025 at 05:57:07PM -0400, Peter Geoghegan wrote:
> 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.

Yes, I understand this "loose index scan" feature as preventing DISTINCT
from traversing all matching indexed values, and then removing
duplicates.  Rather it stops after finding the first match for each
distinct value.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.