Re: First draft of PG 17 release notes

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>

To: David Rowley <dgrowleyml@gmail.com>

Cc: Peter Geoghegan <pg@bowt.ie>, torikoshia <torikoshia@oss.nttdata.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2024-05-28T04:20:21Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands
- 3890d90c1508 18.0 cited
When creating materialized views, use REFRESH to load data.
- b4da732fd64e 17.0 cited
Revert temporal primary keys and foreign keys
- 8aee330af55d 17.0 cited
Avoid needless large memcpys in libpq socket writing
- c4ab7da60617 17.0 cited
Enhance nbtree ScalarArrayOp execution.
- 5bf748b86bc6 17.0 cited
Introduce a non-recursive JSON parser
- 3311ea86edc7 17.0 cited
Combine freezing and pruning steps in VACUUM
- 6dbb490261a6 17.0 cited
Allow SIGINT to cancel psql database reconnections.
- cafe1056558f 17.0 cited
Provide API for streaming relation data.
- b5a9b18cd0bc 17.0 cited
Add hash support functions and hash opclass for contrib/ltree.
- 485f0aa85995 17.0 cited
Pull up ANY-SUBLINK with the necessary lateral support.
- 9f133763961e 17.0 cited
Read WAL directly from WAL buffers.
- 91f2cae7a4e6 17.0 cited
Introduce the dynamic shared memory registry.
- 8b2bcf3f287c 17.0 cited
Add macros for looping through a List without a ListCell.
- 14dd0f27d7cd 17.0 cited
Support +/- infinity in the interval data type.
- 519fc1bd9e9d 17.0 cited
Extend ALTER OPERATOR to allow setting more optimization attributes.
- 2b5154beab79 17.0 cited
Consider cheap startup paths in add_paths_to_append_rel
- a8a968a8212e 17.0 cited

On Tue, May 28, 2024 at 02:44:28PM +1200, David Rowley wrote:
> On Sun, 26 May 2024 at 15:57, Bruce Momjian <bruce@momjian.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".

Okay, I went with:

	Allow btree indexes to more efficiently find a set of values,
	such as those supplied by IN clauses using constants (Peter Geoghegan,
	Matthias van de Meent)


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

  Only you can decide what is important to you.