| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: First draft of PG 17 release notes |
| Date: | 2024-05-28 02:44:28 |
| Message-ID: | CAApHDvqmW0wQRam4paRbHvLQA+w5CJOCno4BCu=NFRLRhYhtRw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 26 May 2024 at 15:57, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> 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?
I think this needs further adjustment. An "IN subquery" is an IN
clause which contains a subquery. As far as I understand it,
5bf748b86 does nothing to improve those. It's there to improve IN with
a set of values such as IN(1,2,3).
Maybe "IN subqueries" can be replaced with "an SQL IN clause".
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2024-05-28 04:20:21 | Re: First draft of PG 17 release notes |
| Previous Message | arne.roland | 2024-05-28 01:43:27 | Re: apply_scanjoin_target_to_paths and partitionwise join |