On 8/31/22 8:15 PM, Justin Pryzby wrote:
> On Tue, Aug 30, 2022 at 03:58:48PM -0400, Jonathan S. Katz wrote:
>
>> In this latest release, PostgreSQL improves on its in-memory and on-disk sorting
>> algorithms, with benchmarks showing speedups of 25% - 400% based on sort types.
>
> rather than "based on": "depending on the data types being sorted"
I followed this suggestion but modified it in a different way. Still,
I'm not sure if this conveys the full breadth of the features. I wonder
if we should expand on the sorting changes more?
>
>> Building on work from the previous PostgreSQL release for allowing async remote
>> queries, the PostgreSQL foreign data wrapper, `postgres_fdw`, can now commit
>> transactions in parallel.
>
> asynchronous
Modified.
>> benefits for certain workloads. On certain operating systems, PostgreSQL 15
>
> s/certain/some ?
I think "some" sounds like "it may or may not work" vs. "certain" says
that it "can work with tuning". We still want to ensure that people are
excited about the feature and try it out.
>> supports the ability to prefetch WAL file contents and speed up recovery times.
>
>> PostgreSQL's built-in backup command, `pg_basebackup`, now supports server-side
>> compression of backup files with a choice of gzip, LZ4, and zstd.
>
> remove "server-side", since they're also supported on the client-side.
The server-side feature is the new piece for PG15. Gzip was already
supported on the client-side; lz4 + zstd are new for PG15.
I think the server-side compression is the part to call out, as you can
benefit from that existing on the server prior to transferring the
backup elsewhere, and have that network savings. However, happy to be
told that we should discuss both server/client compression in the
announcement.
>> the caller, not the view creator. This option, called `security_invoker`, adds
>> an additional layer of protection to ensure view callers have the correct
>> permissions for working with the underlying data.
>
> ensure *that ?
Fixed.
>> alter server-level configuration parameters. Additionally, users can now search
>> for information about configuration using the `\dconfig` command from the `psql`
>> command-line tool.
>
> rather than "search for information about configuration", say "list
> configuration information" ?
You can search though -- it supports wildcards. I understand the point
-- really you are still listing it out, but I think one of the neat
things is I can fairly easily search for the name of a config parameter
from the CLI, even if I can't remember the correct or full name of it.
>> PostgreSQL server-level statistics are now collected in shared memory,
>> eliminating the statistics collector process and writing these stats to disk.
>
> and *the need to periodically* write these stats to disk
Modified this. However, does this appropriately capture the performance
benefit of having the server-level stats collection modified in this
way? Does it capture all the benefits?
New version attached.
Thanks,
Jonathan
