PostgreSQL 17 Beta 1 release announcement draft

Thanks for writing that up. It's always exciting to see this each year.

On Thu, 16 May 2024 at 13:45, Jonathan S. Katz <jkatz@postgresql.org> wrote:

* Please indicate if you believe there's a notable omission, or if we
should omit any of these callouts

I'd say the streaming read stuff added in b5a9b18cd and subsequent
commits like b7b0f3f27 and 041b96802 are worth a mention. I'd be happy
to see this over the IS NOT NULL qual stuff that I worked on in there
or even the AVX512 bit counting. Speeding up a backwater aggregate
function is nice, but IMO, not compatible with reducing the number
reads.

There's some benchmarking in a youtube video:
https://youtu.be/QAYzWAlxCYc?si=L0UT6Lrf067ZBv46&amp;t=237

* Please indicate if a description is confusing - I'm happy to rewrite
to ensure it's clearer.

Please provide feedback no later than Wed 2024-05-22 18:00 UTC.

The only other thing I saw from a quick read was a stray "the" in "the
copy proceed even if the there is an error inserting a row."

David

Hi Jonathan

Did the review and did not find any issues.

Regards
Kashif Zeeshan
Bitnine Global

On Thu, May 16, 2024 at 6:45 AM Jonathan S. Katz <jkatz@postgresql.org>
wrote:

On Thu, May 16, 2024, 02:45 Jonathan S. Katz <jkatz@postgresql.org> wrote:

Hi,

Attached is a copy of the PostgreSQL 17 Beta 1 release announcement
draft. This contains a user-facing summary of some of the features that
will be available in the Beta, as well as a call to test. I've made an
effort to group them logically around the different workflows they affect.

A few notes:

* The section with the features is not 80-char delimited. I will do that
before the final copy

* There is an explicit callout that we've added in the SQL/JSON features
that were previously reverted in PG15. I want to ensure we're
transparent about that, but also use it as a hook to get people testing.

When reviewing:

* Please check for correctness of feature descriptions, keeping in mind
this is targeted for a general audience

* Please indicate if you believe there's a notable omission, or if we
should omit any of these callouts

* Please indicate if a description is confusing - I'm happy to rewrite
to ensure it's clearer.

Please provide feedback no later than Wed 2024-05-22 18:00 UTC. As the
beta release takes some extra effort, I want to ensure all changes are
in with time to spare before release day.

"Now as of PostgreSQL 17, you can now use parallel index builds for [BRIN](
https://www.postgresql.org/docs/17/brin.html) indexes."

The 2nd "now" is redundant.

"Finally, PostgreSQL 17 adds more explicitly SIMD instructions, including
AVX-512 support for the [`bit_count](
https://www.postgresql.org/docs/17/functions-bitstring.html) function."

Would "SIMD-explicit instructions" be better? Also, I know you may not be
using markdown for the final version, but the bit_count backtick isn't
matched by a closing backtick.

"[`COPY`](https://www.postgresql.org/docs/17/sql-copy.html), used to
efficiently bulk load data into PostgreSQL"

The "used to" makes me stumble into reading it as meaning "it previously
could efficiently bulk load data".

Perhaps just add a "which is" before "used"?

"PostgreSQL 17 includes a built-in collation provider that provides similar
semantics to the `C` collation provided by libc."

"provider", "provides", and "provided" feels too repetitive.

How about, "PostgreSQL 17 includes a built-in collation provider with
semantics similar to the `C` collation offered by libc."?

Regards

Thom

Hi,

On Wed, May 15, 2024 at 09:45:35PM -0400, Jonathan S. Katz wrote:

Hi,

Attached is a copy of the PostgreSQL 17 Beta 1 release announcement draft.

Thanks for working on it!

I've one comment:

PostgreSQL 17 also introduces a new view, [`pg_wait_events`](https://www.postgresql.org/docs/17/view-pg-wait-events.html), which provides descriptions about wait events and can be combined with `pg_stat_activity` to give more insight into an operation.

Instead of "to give more insight into an operation", what about "to give more
insight about what a session is waiting for (should it be active)"?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Hello,

I am trying to open the 17 docs but it looks removed. Getting
following message "Page not found"

https://www.postgresql.org/docs/17/

Regards,
Zaid Shabbir

On Thu, May 16, 2024 at 10:16 AM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:

On Thu, May 16, 2024, 06:37 zaidagilist <zaidagilist@gmail.com> wrote:

Hello,

I am trying to open the 17 docs but it looks removed. Getting
following message "Page not found"

https://www.postgresql.org/docs/17/

Regards,
Zaid Shabbir

That link isn't set up yet, but will be (or should be) when the
announcement goes out.

Regards

Thom

On Thu, 16 May 2024 at 17:37, zaidagilist <zaidagilist@gmail.com> wrote:

I am trying to open the 17 docs but it looks removed. Getting
following message "Page not found"

https://www.postgresql.org/docs/17/

It's called "devel" for "development" until we branch sometime before July:

https://www.postgresql.org/docs/devel/

David

On Thu, 16 May 2024 at 03:45, Jonathan S. Katz <jkatz@postgresql.org> wrote:

Attached is a copy of the PostgreSQL 17 Beta 1 release announcement
draft.

I think we can quickly mention c4ab7da6061 in the COPY paragraph, in
some benchmarks it improved perf by close to 2x. Something like this:
"has improved performance in PostgreSQL 17 when the source encoding
matches the destination encoding *and when sending large rows from
server to client*"

Also, I think it's a bit weird to put the current COPY paragraph under
Developer Experience. I think if you want to keep it there instead of
move it to the per section, we should put the line about IGNORE_ERROR
first instead of the perf improvements. Now the IGNORE_ERROR addition
seems more of an afterthought.

s/IGNORE_ERROR/ON_ERROR

I think it would be good to clarify if the following applies when
upgrading from or to PostgreSQL 17:
"Starting with PostgreSQL 17, you no longer need to drop logical
replication slots when using pg_upgrade"

Finally, I personally would have included a lot more links for the new
items in this document. Some that would benefit from being a link
imho:
- pg_createsubscriber
- JSON_TABLE
- SQL/JSON constructor
- SQL/JSON query functions
- ON_ERROR
- sslnegotiation
- PQchangePassword
- pg_maintain

On 5/15/24 21:45, Jonathan S. Katz wrote:

Please provide feedback no later than Wed 2024-05-22 18:00 UTC. As the
beta release takes some extra effort, I want to ensure all changes are
in with time to spare before release day.

"You can find information about all of the features and changes found in
PostgreSQL 17"

Sounds repetitive; maybe:

"Information about all of the features and changes in PostgreSQL 17 can
be found in the [release notes]"

"more explicitly SIMD instructions" I think ought to be "more explicit
SIMD instructions"

"PostgreSQL 17 includes a built-in collation provider that provides
similar semantics to the `C` collation provided by libc."

I think that needs to mention UTF-8 encoding somehow, and "provided by
libc" is not really true; maybe:

"PostgreSQL 17 includes a built-in collation provider that provides
similar sorting semantics to the `C` collation except with UTF-8
encoding rather than SQL_ASCII."

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

On 5/16/24 08:05, Joe Conway wrote:

On 5/15/24 21:45, Jonathan S. Katz wrote:

Please provide feedback no later than Wed 2024-05-22 18:00 UTC. As the
beta release takes some extra effort, I want to ensure all changes are
in with time to spare before release day.

"`EXPLAIN` can now show how much time is spent for I/O block reads and
writes"

Is that really EXPLAIN, or rather EXPLAIN ANALYZE?

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

On 5/15/24 10:42 PM, David Rowley wrote:

Thanks for writing that up. It's always exciting to see this each year.

On Thu, 16 May 2024 at 13:45, Jonathan S. Katz <jkatz@postgresql.org> wrote:

* Please indicate if you believe there's a notable omission, or if we
should omit any of these callouts

I'd say the streaming read stuff added in b5a9b18cd and subsequent
commits like b7b0f3f27 and 041b96802 are worth a mention. I'd be happy
to see this over the IS NOT NULL qual stuff that I worked on in there
or even the AVX512 bit counting. Speeding up a backwater aggregate
function is nice, but IMO, not compatible with reducing the number
reads.
There's some benchmarking in a youtube video:
https://youtu.be/QAYzWAlxCYc?si=L0UT6Lrf067ZBv46&amp;t=237

Nice! Definitely agree on including this - it wasn't initially clear to
me on the read of the release notes. I'll update it. Please see in the
next revision (will posted upthread), proposed text here for
convenience, as I'm not sure I'm appropriately capturing it:

==
This release introduces adds an interface to stream I/O, and can show
performance improvements when performing sequential scans and running
[`ANALYZE`](https://www.postgresql.org/docs/17/sql-analyze.html).
==

The AVX-512 bit counting showed solid impact[1]https://github.com/pgvector/pgvector/pull/519 on the binary distance
functions in pgvector (I have to re-run again w/v17, as I seem to recall
seeing some numbers that boosted it 5-7x [but recall isn't 100% ;)]).

* Please indicate if a description is confusing - I'm happy to rewrite
to ensure it's clearer.

Please provide feedback no later than Wed 2024-05-22 18:00 UTC.

The only other thing I saw from a quick read was a stray "the" in "the
copy proceed even if the there is an error inserting a row."

Thanks!

Jonathan

[1]: https://github.com/pgvector/pgvector/pull/519

On 5/16/24 1:10 AM, Thom Brown wrote:

On Thu, May 16, 2024, 02:45 Jonathan S. Katz <jkatz@postgresql.org
<mailto:jkatz@postgresql.org>> wrote:

Hi,

Attached is a copy of the PostgreSQL 17 Beta 1 release announcement
draft. This contains a user-facing summary of some of the features that
will be available in the Beta, as well as a call to test. I've made an
effort to group them logically around the different workflows they
affect.

A few notes:

* The section with the features is not 80-char delimited. I will do
that
before the final copy

* There is an explicit callout that we've added in the SQL/JSON
features
that were previously reverted in PG15. I want to ensure we're
transparent about that, but also use it as a hook to get people testing.

When reviewing:

* Please check for correctness of feature descriptions, keeping in mind
this is targeted for a general audience

* Please indicate if you believe there's a notable omission, or if we
should omit any of these callouts

* Please indicate if a description is confusing - I'm happy to rewrite
to ensure it's clearer.

Please provide feedback no later than Wed 2024-05-22 18:00 UTC. As the
beta release takes some extra effort, I want to ensure all changes are
in with time to spare before release day.

"Now as of PostgreSQL 17, you can now use parallel index builds for
[BRIN](https://www.postgresql.org/docs/17/brin.html
<https://www.postgresql.org/docs/17/brin.html&gt;) indexes."

The 2nd "now" is redundant.

"Finally, PostgreSQL 17 adds more explicitly SIMD instructions,
including AVX-512 support for the
[`bit_count](https://www.postgresql.org/docs/17/functions-bitstring.html
<https://www.postgresql.org/docs/17/functions-bitstring.html&gt;) function."

Would "SIMD-explicit instructions" be better? Also, I know you may not
be using markdown for the final version, but the bit_count backtick
isn't matched by a closing backtick.

"[`COPY`](https://www.postgresql.org/docs/17/sql-copy.html
<https://www.postgresql.org/docs/17/sql-copy.html&gt;), used to efficiently
bulk load data into PostgreSQL"

The "used to" makes me stumble into reading it as meaning "it previously
could efficiently bulk load data".

Perhaps just add a "which is" before "used"?

"PostgreSQL 17 includes a built-in collation provider that provides
similar semantics to the `C` collation provided by libc."

"provider", "provides", and "provided" feels too repetitive.

How about, "PostgreSQL 17 includes a built-in collation provider with
semantics similar to the `C` collation offered by libc."?

Thanks - I accepted (with modifications) most of the suggestions here.
I'll include in the next version of the draft.

Jonathan

On 5/16/24 1:15 AM, Bertrand Drouvot wrote:

Hi,

On Wed, May 15, 2024 at 09:45:35PM -0400, Jonathan S. Katz wrote:

Hi,

Attached is a copy of the PostgreSQL 17 Beta 1 release announcement draft.

Thanks for working on it!

I've one comment:

PostgreSQL 17 also introduces a new view, [`pg_wait_events`](https://www.postgresql.org/docs/17/view-pg-wait-events.html), which provides descriptions about wait events and can be combined with `pg_stat_activity` to give more insight into an operation.

Instead of "to give more insight into an operation", what about "to give more
insight about what a session is waiting for (should it be active)"?

I put:

"to give more in insight into why a session is blocked."

Does that work?

Jonathan

On 5/16/24 6:41 AM, Jelte Fennema-Nio wrote:

On Thu, 16 May 2024 at 03:45, Jonathan S. Katz <jkatz@postgresql.org> wrote:

Attached is a copy of the PostgreSQL 17 Beta 1 release announcement
draft.

I think we can quickly mention c4ab7da6061 in the COPY paragraph, in
some benchmarks it improved perf by close to 2x. Something like this:
"has improved performance in PostgreSQL 17 when the source encoding
matches the destination encoding *and when sending large rows from
server to client*"

(I'm going to make a note to test this with loading large vectors :)
I've modified the text to reflect this. Please see the new language
upthread.

Also, I think it's a bit weird to put the current COPY paragraph under
Developer Experience. I think if you want to keep it there instead of
move it to the per section, we should put the line about IGNORE_ERROR
first instead of the perf improvements. Now the IGNORE_ERROR addition
seems more of an afterthought.

I don't agree with this. I think we want to push COPY as a developer
feature - I see a lot of people not utilizing COPY appropriate when it
would really benefit the performance of their app, and I think
emphasizing it as the way to do bulk loads (while touting that it's even
faster!) will help make it more apparent.

s/IGNORE_ERROR/ON_ERROR

Thanks.

I think it would be good to clarify if the following applies when
upgrading from or to PostgreSQL 17:
"Starting with PostgreSQL 17, you no longer need to drop logical
replication slots when using pg_upgrade"

Adjusted.

Finally, I personally would have included a lot more links for the new
items in this document. Some that would benefit from being a link
imho:
- pg_createsubscriber
- JSON_TABLE
- SQL/JSON constructor
- SQL/JSON query functions
- ON_ERROR
- sslnegotiation
- PQchangePassword
- pg_maintain

I have to check if these have deep links or not, but I was planning to
make another pass once the copy (no pun intended) is closer to
finalized, so I don't have to constantly edit markdown.

Jonathan

On 5/16/24 8:05 AM, Joe Conway wrote:

On 5/15/24 21:45, Jonathan S. Katz wrote:

Please provide feedback no later than Wed 2024-05-22 18:00 UTC. As the
beta release takes some extra effort, I want to ensure all changes are
in with time to spare before release day.

"You can find information about all of the features and changes found in
PostgreSQL 17"

Sounds repetitive; maybe:

"Information about all of the features and changes in PostgreSQL 17 can
be found in the [release notes]"

The first is active voice, the suggestion passive. However, I tightened
the language:

You can find information about all of the PostgreSQL 17 features and
changes in the [release
notes](https://www.postgresql.org/docs/17/release-17.html):

"PostgreSQL 17 includes a built-in collation provider that provides
similar semantics to the `C` collation provided by libc."

I think that needs to mention UTF-8 encoding somehow, and "provided by
libc" is not really true; maybe:

"PostgreSQL 17 includes a built-in collation provider that provides
similar sorting semantics to the `C` collation except with UTF-8
encoding rather than SQL_ASCII."

WFM. Taken verbatim.

Thanks,

Jonathan

On 5/15/24 9:45 PM, Jonathan S. Katz wrote:

Hi,

Attached is a copy of the PostgreSQL 17 Beta 1 release announcement
draft. This contains a user-facing summary of some of the features that
will be available in the Beta, as well as a call to test. I've made an
effort to group them logically around the different workflows they affect.

A few notes:

* The section with the features is not 80-char delimited. I will do that
before the final copy

* There is an explicit callout that we've added in the SQL/JSON features
that were previously reverted in PG15. I want to ensure we're
transparent about that, but also use it as a hook to get people testing.

When reviewing:

* Please check for correctness of feature descriptions, keeping in mind
this is targeted for a general audience

* Please indicate if you believe there's a notable omission, or if we
should omit any of these callouts

* Please indicate if a description is confusing - I'm happy to rewrite
to ensure it's clearer.

Please provide feedback no later than Wed 2024-05-22 18:00 UTC. As the
beta release takes some extra effort, I want to ensure all changes are
in with time to spare before release day.

Thanks for all the feedback to date. Please see the next revision.
Again, please provide feedback no later than 2024-05-22 18:00 UTC.

Thanks,

Jonathan

Op 5/19/24 om 23:34 schreef Jonathan S. Katz:

On 5/15/24 9:45 PM, Jonathan S. Katz wrote:

Hi,

Attached is a copy of the PostgreSQL 17 Beta 1 release announcement

'This release introduces adds an interface' should be:
'This release adds an interface'
(or 'introduces'; just not both...)

Thanks,

Erik Rijkers

On Mon, 20 May 2024 at 09:35, Jonathan S. Katz <jkatz@postgresql.org> wrote:

Thanks for all the feedback to date. Please see the next revision.
Again, please provide feedback no later than 2024-05-22 18:00 UTC.

Thanks for the updates.

[`COPY`](https://www.postgresql.org/docs/17/sql-copy.html) is used to efficiently bulk load data into PostgreSQL, and with PostgreSQL 17 shows a 2x performance improvement when loading large rows.

The 2x thing mentioned by Jelte is for COPY TO rather than COPY FROM.
So I think "exporting" or "sending large rows to the client" rather
than "loading".

There's also a stray "with" in that sentence.

David

Hi Jon,

Regarding vacuum "has shown up to a 6x improvement in overall time to
complete its work" -- I believe I've seen reported numbers close to
that only 1) when measuring the index phase in isolation or maybe 2)
the entire vacuum of unlogged tables with one, perfectly-correlated
index (testing has less variance with WAL out of the picture). I
believe tables with many indexes would show a lot of improvement, but
I'm not aware of testing that case specifically. Can you clarify where
6x came from?