public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Peter Geoghegan <[email protected]>
Cc: torikoshia <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: First draft of PG 17 release notes
Date: Sat, 25 May 2024 23:57:01 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAH2-WznwSs5irUka2deUooSdH7Sts2oPdVv4PCOwhK51fq2ZTg@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CAH2-WznwSs5irUka2deUooSdH7Sts2oPdVv4PCOwhK51fq2ZTg@mail.gmail.com>
On Thu, May 23, 2024 at 08:19:15PM -0400, Peter Geoghegan wrote:
> On Wed, May 22, 2024 at 6:50 PM Bruce Momjian <[email protected]> wrote:
> > Agreed, patch applied, thanks.
>
> The item for my commit 5bf748b8 currently reads:
>
> "Allow btree indexes to more efficiently find array matches"
>
> I think that this isn't likely to mean much to most users. It seems
> like it'd be a lot clearer if the wording was more in line with the
> beta1 announcement, which talks about the work as an enhancement to
> index scans that use an IN ( ) condition. Specifically referencing
> IN() (as opposed to something about arrays or array conditions) is
> likely to make the item much more understandable.
>
> Referencing array matches makes me think of a GIN index on an array
> column. While ScalarArrayOps do use an array under the cover, that's
> mostly an implementation detail. At least it is to users that
> exclusively use IN(), likely the majority (that's the SQL standard
> syntax).
>
> For context, the Postgres 9.2 release notes described the feature that
> my work directly built on as follows:
>
> "Allow indexed_col op ANY(ARRAY[...]) conditions to be used in plain
> index scans and index-only scans"
>
> This was a very accurate description of this earlier work. Similar
> wording could be used now, but that doesn't seem great to me either.
> Simply because this wording also doesn't reference IN() conditions in
> index quals.
Agreed. I changed it to:
Allow btree indexes to more efficiently find a set of values, such as
those supplied by IN subqueries
Is that good?
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
view thread (146+ 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: First draft of PG 17 release notes
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