Date: Mon, 18 Jul 2022 20:23:23 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: First draft of the PG 15 release notes
Message-ID: <20220719012322.GD12702@telsasoft.com>
References: <YnqIT8kpiO3m6SD7@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YnqIT8kpiO3m6SD7@momjian.us>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20220719012322.GD12702%40telsasoft.com>
Precedence: bulk

> Increase hash_mem_multiplier default to 2.0 (Peter Geoghegan)
> This allows query hash operations to use double the amount of work_mem memory as other operations.

I wonder if it's worth pointing out that a query may end up using not just 2x
more memory (since work_mem*hash_mem_multiplier is per node), but 2**N more,
for N nodes.

> Remove pg_dump's --no-synchronized-snapshots option since all supported server versions support synchronized snapshots (Tom Lane)

It'd be better to put that after the note about dropping support for upgrading
clusters older than v9.2 in psql/pg_dump/pg_upgrade.

> Enable system and TOAST btree indexes to efficiently store duplicates (Peter Geoghegan)

Say "btree indexes on system [and TOAST] tables"

> Prevent changes to columns only indexed by BRIN indexes from disabling HOT updates (Josef Simanek)

This was reverted

> Generate periodic log message during slow server starts (Nitin Jadhav, Robert Haas)
messages plural

> Messages report the cause of the delay. The time interval for notification is controlled by the new server variable log_startup_progress_interval.
*The messages

> Add server variable shared_memory_size to report the size of allocated shared memory (Nathan Bossart)
> Add server variable shared_memory_size_in_huge_pages to report the number of huge memory pages required (Nathan Bossart)

Maybe these should say server *parameter* since they're not really "variable".

> 0. Add support for LZ4 and Zstandard compression of server-side base backups (Jeevan Ladhe, Robert Haas)
> 1. Allow pg_basebackup to use LZ4 and Zstandard compression on server-side base backup files (Dipesh Pandit, Jeevan Ladhe)
> 2. Allow pg_basebackup's --compress option to control the compression method and options (Michael Paquier, Robert Haas)
>    New options include server-gzip (gzip on the server), client-gzip (same as gzip).
> 3. Allow pg_basebackup to compress on the server side and decompress on the client side before storage (Dipesh Pandit)
>    This is accomplished by specifying compression on the server side and plain output format.

I still think these expose the incremental development rather than the
user-facing change.

1. It seems wrong to say "server-side" since client-side compression with
LZ4/zstd is also supported.

2. It's confusing to say that the new options are server-gzip and client-gzip,
since it just mentioned new algorithms;

3. I'm not sure this needs to be mentioned at all; maybe it should be a
"detail" following the item about server-side compression.

> Tables added to the listed schemas in the future will also be replicated.

"Tables later added" is clearer.  Otherwise "in the future" sounds like maybe
in v16 or v17 we'll start replicating those tables.

> Allow subscribers to stop logical replication application on error (Osumi Takamichi, Mark Dilger)
"application" sounds off.

> Add new default WAL-logged method for database creation (Dilip Kumar)
"New default" sounds off.  Say "Add new WAL-logged method for database creation, used by default".

> Have pg_upgrade preserve relfilenodes, tablespace, and database OIDs between old and new clusters (Shruthi KC, Antonin Houska)

"tablespace OIDs" or "tablespace and database OIDs and relfilenodes"

> Limit support of pg_upgrade to old servers running PostgreSQL 9.2 and later (Tom Lane)

The word "old" doesn't appear in the 2 release notes items about pg_dump and
psql, and "old" makes it sound sounds like "antique" rather than "source".

> Some internal-use-only types have also been assigned this column.
this *value

> Allow custom scan provders to indicate if they support projections (Sven Klemm)
> The default is now that custom scan providers can't support projections, so they need to be updated for this release.

Per the commit message, they don't "need" to be updated.
I think this should say "The default now assumes that a custom scan provider
does not support projections; to retain optimal performance, they should be
updated to indicate whether that's supported.