Release 14 Schedule
Greetings
The Release Management Team (Michael Paquier, Peter Geoghegan and
myself) in consultation with the release team proposes the following
release schedule:
* PostgreSQL 14 Release Candidate 1 (RC1) will be released on September 23, 2021.
* In the absence of any critical issues, PostgreSQL 14 will become generally available on September 30, 2021.
All commits and fixes intended for this release should be made before September 23, 2021 AoE.
We would like to thank all the contributors. reviewers and committers for their work on this release, and for making this a fairly smooth process.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On Wed, Sep 15, 2021 at 8:56 AM Andrew Dunstan <andrew@dunslane.net> wrote:
The Release Management Team (Michael Paquier, Peter Geoghegan and
myself) in consultation with the release team proposes the following
release schedule:* PostgreSQL 14 Release Candidate 1 (RC1) will be released on September 23, 2021.
* In the absence of any critical issues, PostgreSQL 14 will become generally available on September 30, 2021.
All commits and fixes intended for this release should be made before September 23, 2021 AoE.
Presumably this needs to be a couple days earlier, right? Tom would
probably stamp on Monday, so I guess fixes should be in by Sunday at
the very latest to allow for a full buildfarm cycle.
Also, I really like the fact that we're looking to release in
September! I think that's nicer than when it slips into October.
--
Robert Haas
EDB: http://www.enterprisedb.com
On 9/15/21 10:20 AM, Robert Haas wrote:
On Wed, Sep 15, 2021 at 8:56 AM Andrew Dunstan <andrew@dunslane.net> wrote:
The Release Management Team (Michael Paquier, Peter Geoghegan and
myself) in consultation with the release team proposes the following
release schedule:* PostgreSQL 14 Release Candidate 1 (RC1) will be released on September 23, 2021.
* In the absence of any critical issues, PostgreSQL 14 will become generally available on September 30, 2021.
All commits and fixes intended for this release should be made before September 23, 2021 AoE.
Presumably this needs to be a couple days earlier, right? Tom would
probably stamp on Monday, so I guess fixes should be in by Sunday at
the very latest to allow for a full buildfarm cycle.
Good point. Let's say Sunday 19th. There are in fact very few open
items, so the release 14 branch should already be fairly quiet.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
The Release Management Team (Michael Paquier, Peter Geoghegan and
myself) in consultation with the release team proposes the following
release schedule:
* PostgreSQL 14 Release Candidate 1 (RC1) will be released on September 23, 2021.
* In the absence of any critical issues, PostgreSQL 14 will become generally available on September 30, 2021.
We don't yet have a list-of-major-features for the v14 release notes.
Anybody care to propose one?
regards, tom lane
On Sat, Sep 18, 2021 at 01:37:19PM -0400, Tom Lane wrote:
We don't yet have a list-of-major-features for the v14 release notes.
Anybody care to propose one?
. Allow extended statistics on column expressions;
. Memoize node which can improve speed of nested loop joins;
. Allow use of LZ4 compression for faster access to TOASTed fields;
. JSONB and H-store types may be subscripted, as may be participating data types provided by extensions.
. Many improvements to performance of VACUUM;
Maybe these??
Improve the performance of updates/deletes on partitioned tables when only a few partitions are affected (Amit Langote, Tom Lane)
Add SQL-standard SEARCH and CYCLE clauses for common table expressions (Peter Eisentraut)
Allow REINDEX to process all child tables or indexes of a partitioned relation (Justin Pryzby, Michael Paquier)
BTW I wondered if this should be mentioned as an incompatibile change:
commit 3d351d916b20534f973eda760cde17d96545d4c4
Redefine pg_class.reltuples to be -1 before the first VACUUM or ANALYZE.
--
Justin
On 9/19/21 12:32 PM, Justin Pryzby wrote:
On Sat, Sep 18, 2021 at 01:37:19PM -0400, Tom Lane wrote:
We don't yet have a list-of-major-features for the v14 release notes.
Anybody care to propose one?. Allow extended statistics on column expressions;
. Memoize node which can improve speed of nested loop joins;
. Allow use of LZ4 compression for faster access to TOASTed fields;
. JSONB and H-store types may be subscripted, as may be participating data types provided by extensions.
. Many improvements to performance of VACUUM;Maybe these??
I would propose a few different ones. I'm looking at the overall breadth
of user impact as I propose these and the reactions I've seen in the field.
- General performance improvements for databases with multiple
connections (the MVCC snapshot work).
- The reduction in bloat on frequently updated B-trees; that was a
longstanding complaint against PostgreSQL that was resolved.
- I agree with the JSON improvements; I'd bucket this in data types and
include the support of multiranges.
- Logical decoding / replication received some significant performance
improvements
- Many improvements in query parallelism. One that stands out is how
parallel queries can be leveraged using FDWs now, in particular the
postgres_fdw.
- I agree with VACUUM suggestion as well.
I can try proposing some wording on this in a bit; I'm working on the
overdue draft of the press release, and thought I'd chime in here first.
Thanks,
Jonathan
On Mon, Sep 20, 2021 at 3:15 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 9/19/21 12:32 PM, Justin Pryzby wrote:
On Sat, Sep 18, 2021 at 01:37:19PM -0400, Tom Lane wrote:
We don't yet have a list-of-major-features for the v14 release notes.
Anybody care to propose one?. Allow extended statistics on column expressions;
. Memoize node which can improve speed of nested loop joins;
. Allow use of LZ4 compression for faster access to TOASTed fields;
. JSONB and H-store types may be subscripted, as may be participating data types provided by extensions.
. Many improvements to performance of VACUUM;Maybe these??
I would propose a few different ones. I'm looking at the overall breadth
of user impact as I propose these and the reactions I've seen in the field.- General performance improvements for databases with multiple
connections (the MVCC snapshot work).- The reduction in bloat on frequently updated B-trees; that was a
longstanding complaint against PostgreSQL that was resolved.- I agree with the JSON improvements; I'd bucket this in data types and
include the support of multiranges.- Logical decoding / replication received some significant performance
improvements- Many improvements in query parallelism. One that stands out is how
parallel queries can be leveraged using FDWs now, in particular the
postgres_fdw.- I agree with VACUUM suggestion as well.
+1 to this list. One enhancement which we might want to consider is:
Improve the performance of updates/deletes on partitioned tables when
only a few partitions are affected (Amit Langote, Tom Lane)
I think this will be quite useful for customers using partitions.
--
With Regards,
Amit Kapila.
Observability-related improvements are also good and very important for the
future of DBA operations -- compute_query_id, new pg_stat_**, etc.
Things like new knob idle_session_timeout and restore_command change not
requiring a restart will be very noticeable too.
On Sun, Sep 19, 2021 at 2:45 PM Jonathan S. Katz <jkatz@postgresql.org>
wrote:
Show quoted text
On 9/19/21 12:32 PM, Justin Pryzby wrote:
On Sat, Sep 18, 2021 at 01:37:19PM -0400, Tom Lane wrote:
We don't yet have a list-of-major-features for the v14 release notes.
Anybody care to propose one?. Allow extended statistics on column expressions;
. Memoize node which can improve speed of nested loop joins;
. Allow use of LZ4 compression for faster access to TOASTed fields;
. JSONB and H-store types may be subscripted, as may be participatingdata types provided by extensions.
. Many improvements to performance of VACUUM;
Maybe these??
I would propose a few different ones. I'm looking at the overall breadth
of user impact as I propose these and the reactions I've seen in the field.- General performance improvements for databases with multiple
connections (the MVCC snapshot work).- The reduction in bloat on frequently updated B-trees; that was a
longstanding complaint against PostgreSQL that was resolved.- I agree with the JSON improvements; I'd bucket this in data types and
include the support of multiranges.- Logical decoding / replication received some significant performance
improvements- Many improvements in query parallelism. One that stands out is how
parallel queries can be leveraged using FDWs now, in particular the
postgres_fdw.- I agree with VACUUM suggestion as well.
I can try proposing some wording on this in a bit; I'm working on the
overdue draft of the press release, and thought I'd chime in here first.Thanks,
Jonathan
On 9/20/21 2:33 AM, Nikolay Samokhvalov wrote:
Observability-related improvements are also good and very important for
the future of DBA operations -- compute_query_id, new pg_stat_**, etc.Things like new knob idle_session_timeout and restore_command change not
requiring a restart will be very noticeable too.
I agree on the observability enhancements (the PR draft gives a bunch of
coverage on this) and the usefulness on the knobs.
I think this also highlights that there are a lot of helpful features in
PostgreSQL 14 -- it may be tough to distill them all down into a list
for the release notes themselves. I think typically we try pick 5-7
features to highlight, and we're at about 10 or so proposed.
On the flip side and going off-script, do we need to select only a few
features in the release notes? We can let the press release provide the
general highlights and use that as a spring board to pick out particular
features.
Thanks,
Jonathan
On 21/09/21 14:23, Jonathan S. Katz wrote:
On 9/20/21 2:33 AM, Nikolay Samokhvalov wrote:
Observability-related improvements are also good and very important for
the future of DBA operations -- compute_query_id, new pg_stat_**, etc.Things like new knob idle_session_timeout and restore_command change not
requiring a restart will be very noticeable too.I agree on the observability enhancements (the PR draft gives a bunch of
coverage on this) and the usefulness on the knobs.I think this also highlights that there are a lot of helpful features in
PostgreSQL 14 -- it may be tough to distill them all down into a list
for the release notes themselves. I think typically we try pick 5-7
features to highlight, and we're at about 10 or so proposed.On the flip side and going off-script, do we need to select only a few
features in the release notes? We can let the press release provide the
general highlights and use that as a spring board to pick out particular
features.Thanks,
Jonathan
I suggest that if there are 7 or more, then possibly you should group
them under 2 or 3 headings.
That way it will not look quite so intimidating, and people have a
framework to give them perspective. Also makes it easier for people to
focus on the highlights that they might consider the most important to
themselves.
Cheers,
Gavin
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/19/21 12:32 PM, Justin Pryzby wrote:
On Sat, Sep 18, 2021 at 01:37:19PM -0400, Tom Lane wrote:
We don't yet have a list-of-major-features for the v14 release notes.
Anybody care to propose one?
I can try proposing some wording on this in a bit; I'm working on the
overdue draft of the press release, and thought I'd chime in here first.
I looked over Jonathan's draft press release [1]/messages/by-id/c1e72deb-8f8b-694a-1dc1-12ce671f8b8f@postgresql.org and tried to boil it down
to our usual ten-or-so bullet points for the release notes' introductory
paragraph. I ended up with this (didn't bother with markup yet):
-----
Stored procedures can now return data via OUT parameters.
The SQL-standard SEARCH and CYCLE options for common table expressions
have been implemented.
Range types have been extended by adding multiranges, which allow
representation of noncontiguous data ranges.
Subscripting can now be applied to any data type for which it is a useful
notation, not only arrays. In this release, JSONB and hstore have gained
subscripting operators.
Numerous performance improvements have been made for parallel queries,
heavily-concurrent workloads, partitioned tables, logical replication, and
vacuuming. Notably, foreign data wrappers can now make use of query
parallelism.
B-tree index updates are managed more efficiently, reducing index bloat.
Extended statistics can now be collected on expressions, allowing
better planning results for complex queries.
libpq now has the ability to pipeline multiple queries, which can boost
throughput over high-latency connections.
TOAST data can optionally be compressed with LZ4 instead of the traditional
pglz algorithm.
-----
I'm not entirely sure that the TOAST item should make the cut,
but I feel fairly good about the rest of this list. Thoughts?
regards, tom lane
[1]: /messages/by-id/c1e72deb-8f8b-694a-1dc1-12ce671f8b8f@postgresql.org
On Wed, Sep 22, 2021 at 5:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/19/21 12:32 PM, Justin Pryzby wrote:
On Sat, Sep 18, 2021 at 01:37:19PM -0400, Tom Lane wrote:
We don't yet have a list-of-major-features for the v14 release notes.
Anybody care to propose one?I can try proposing some wording on this in a bit; I'm working on the
overdue draft of the press release, and thought I'd chime in here first.I looked over Jonathan's draft press release [1] and tried to boil it down
to our usual ten-or-so bullet points for the release notes' introductory
paragraph. I ended up with this (didn't bother with markup yet):-----
Stored procedures can now return data via OUT parameters.The SQL-standard SEARCH and CYCLE options for common table expressions
have been implemented.Range types have been extended by adding multiranges, which allow
representation of noncontiguous data ranges.Subscripting can now be applied to any data type for which it is a useful
notation, not only arrays. In this release, JSONB and hstore have gained
subscripting operators.Numerous performance improvements have been made for parallel queries,
heavily-concurrent workloads, partitioned tables, logical replication, and
vacuuming. Notably, foreign data wrappers can now make use of query
parallelism.
"foreign data wrappers and stored procedures/functions" maybe?
B-tree index updates are managed more efficiently, reducing index bloat.
Extended statistics can now be collected on expressions, allowing
better planning results for complex queries.libpq now has the ability to pipeline multiple queries, which can boost
throughput over high-latency connections.TOAST data can optionally be compressed with LZ4 instead of the traditional
pglz algorithm.
-----I'm not entirely sure that the TOAST item should make the cut,
I think it should be t here.
but I feel fairly good about the rest of this list. Thoughts?
I have a feeling emergency mode vacuum fits on that list. Not in the
press release, but in the major features list of the release notes.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
Hello,
Stored procedures can now return data via OUT parameters.
The SQL-standard SEARCH and CYCLE options for common table expressions
have been implemented.
I think that from the application developer point of view very important feature:
* Allow SQL-language functions and procedures to use SQL-standard function bodies
Compiling query, tracking dependencies - very important.
Pavel Luzanov
Postgres Professional: https://postgrespro.com
The Russian Postgres Company
On 9/22/21 11:15 AM, Magnus Hagander wrote:
On Wed, Sep 22, 2021 at 5:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/19/21 12:32 PM, Justin Pryzby wrote:
On Sat, Sep 18, 2021 at 01:37:19PM -0400, Tom Lane wrote:
We don't yet have a list-of-major-features for the v14 release notes.
Anybody care to propose one?I can try proposing some wording on this in a bit; I'm working on the
overdue draft of the press release, and thought I'd chime in here first.I looked over Jonathan's draft press release [1] and tried to boil it down
to our usual ten-or-so bullet points for the release notes' introductory
paragraph. I ended up with this (didn't bother with markup yet):-----
Stored procedures can now return data via OUT parameters.The SQL-standard SEARCH and CYCLE options for common table expressions
have been implemented.Range types have been extended by adding multiranges, which allow
representation of noncontiguous data ranges.Subscripting can now be applied to any data type for which it is a useful
notation, not only arrays. In this release, JSONB and hstore have gained
subscripting operators.Numerous performance improvements have been made for parallel queries,
heavily-concurrent workloads, partitioned tables, logical replication, and
vacuuming. Notably, foreign data wrappers can now make use of query
parallelism."foreign data wrappers and stored procedures/functions" maybe?
+1
B-tree index updates are managed more efficiently, reducing index bloat.
Extended statistics can now be collected on expressions, allowing
better planning results for complex queries.libpq now has the ability to pipeline multiple queries, which can boost
throughput over high-latency connections.TOAST data can optionally be compressed with LZ4 instead of the traditional
pglz algorithm.
-----I'm not entirely sure that the TOAST item should make the cut,
I think it should be t here.
Leaning towards keeping it. If we subbed it, I'd suggest a statement on
the monitoring/observability improvements.
but I feel fairly good about the rest of this list. Thoughts?
I have a feeling emergency mode vacuum fits on that list. Not in the
press release, but in the major features list of the release notes.
Given some recent news I saw floating around, I'd agree with this.
My suggestion on ordering:
- Numerous performance ...
- B-tree...
- Subscripting ...
- Range types ...
- Stored ...
- Extended ...
- SEARCH / CYCLE ...
- libpq ...
- TOAST ...
(- emergency mode vacuum ...)
Jonathan
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/22/21 11:15 AM, Magnus Hagander wrote:
On Wed, Sep 22, 2021 at 5:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Numerous performance improvements have been made for parallel queries,
heavily-concurrent workloads, partitioned tables, logical replication, and
vacuuming. Notably, foreign data wrappers can now make use of query
parallelism.
"foreign data wrappers and stored procedures/functions" maybe?
+1
I thought the point about FDWs was important because actual work (by
FDW authors) is needed to make anything happen. The extra parallelism
inside plpgsql functions doesn't require user effort, so I don't see
that it needs to be called out separately.
I have a feeling emergency mode vacuum fits on that list. Not in the
press release, but in the major features list of the release notes.
Given some recent news I saw floating around, I'd agree with this.
Meh ... if it didn't make the press release's longer list, why is
it critical here?
My suggestion on ordering:
My thought was "SQL features first, then performance".
regards, tom lane
On Wed, Sep 22, 2021 at 12:00:07PM -0400, Jonathan S. Katz wrote:
On 9/22/21 11:15 AM, Magnus Hagander wrote:
On Wed, Sep 22, 2021 at 5:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/19/21 12:32 PM, Justin Pryzby wrote:
On Sat, Sep 18, 2021 at 01:37:19PM -0400, Tom Lane wrote:
We don't yet have a list-of-major-features for the v14 release notes.
Anybody care to propose one?I can try proposing some wording on this in a bit; I'm working on the
overdue draft of the press release, and thought I'd chime in here first.I looked over Jonathan's draft press release [1] and tried to boil it down
to our usual ten-or-so bullet points for the release notes' introductory
paragraph. I ended up with this (didn't bother with markup yet):-----
Stored procedures can now return data via OUT parameters.The SQL-standard SEARCH and CYCLE options for common table expressions
have been implemented.Range types have been extended by adding multiranges, which allow
representation of noncontiguous data ranges.Subscripting can now be applied to any data type for which it is a useful
notation, not only arrays. In this release, JSONB and hstore have gained
subscripting operators.Numerous performance improvements have been made for parallel queries,
heavily-concurrent workloads, partitioned tables, logical replication, and
vacuuming. Notably, foreign data wrappers can now make use of query
parallelism."foreign data wrappers and stored procedures/functions" maybe?
+1
B-tree index updates are managed more efficiently, reducing index bloat.
Extended statistics can now be collected on expressions, allowing
better planning results for complex queries.libpq now has the ability to pipeline multiple queries, which can boost
throughput over high-latency connections.TOAST data can optionally be compressed with LZ4 instead of the traditional
pglz algorithm.
-----I'm not entirely sure that the TOAST item should make the cut,
I think it should be t here.
Leaning towards keeping it. If we subbed it, I'd suggest a statement on
the monitoring/observability improvements.but I feel fairly good about the rest of this list. Thoughts?
I have a feeling emergency mode vacuum fits on that list. Not in the
press release, but in the major features list of the release notes.Given some recent news I saw floating around, I'd agree with this.
My suggestion on ordering:
- Numerous performance ...
- B-tree...
- Subscripting ...
- Range types ...
- Stored ...
- Extended ...
- SEARCH / CYCLE ...
- libpq ...
- TOAST ...
(- emergency mode vacuum ...)
Maybe group the features together into types of features, similar to v11/v12:
https://www.postgresql.org/docs/12/release-12.html
SQL features: SEARCH/CYLCE, subcripting, range, ...
Performance improvements in btree, vacuum, toast...
...
--
Justin
On 9/22/21 12:30 PM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/22/21 11:15 AM, Magnus Hagander wrote:
I have a feeling emergency mode vacuum fits on that list. Not in the
press release, but in the major features list of the release notes.Given some recent news I saw floating around, I'd agree with this.
Meh ... if it didn't make the press release's longer list, why is
it critical here?
Maybe it should have. I can add it to the "vacuum improvements" sentence.
Jonathan
On Wed, Sep 22, 2021 at 6:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On 9/22/21 11:15 AM, Magnus Hagander wrote:
On Wed, Sep 22, 2021 at 5:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Numerous performance improvements have been made for parallel queries,
heavily-concurrent workloads, partitioned tables, logical replication, and
vacuuming. Notably, foreign data wrappers can now make use of query
parallelism."foreign data wrappers and stored procedures/functions" maybe?
+1
I thought the point about FDWs was important because actual work (by
FDW authors) is needed to make anything happen. The extra parallelism
inside plpgsql functions doesn't require user effort, so I don't see
that it needs to be called out separately.
True, but I'm willing to guess we have a lot more people who are using
stored procs with return query and who are going to be very happy
about them now being much faster in cases where parallelism worked,
than we have people who are writing FDWs..
That said, I'm not suggesting we remove the mention of the FDWs, just
that we keep both.
I have a feeling emergency mode vacuum fits on that list. Not in the
press release, but in the major features list of the release notes.Given some recent news I saw floating around, I'd agree with this.
Meh ... if it didn't make the press release's longer list, why is
it critical here?
My take on that is audience. It's an important feature for existing
users of PostgreSQL, and an important change over how the system
behaved before. They are more likely to read the release notes. The
press release is more about reaching people who are not already using
postgres, or who are so but more tangentially.
Maybe that audience take is wrong though, but it is what I based the idea on :)
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Sep 22, 2021 at 6:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I thought the point about FDWs was important because actual work (by
FDW authors) is needed to make anything happen. The extra parallelism
inside plpgsql functions doesn't require user effort, so I don't see
that it needs to be called out separately.
True, but I'm willing to guess we have a lot more people who are using
stored procs with return query and who are going to be very happy
about them now being much faster in cases where parallelism worked,
than we have people who are writing FDWs..
Certainly. But my sentence about "Numerous performance improvements"
already mashes down dozens of other it-just-works-better-now
performance improvements. Wny call out that one in particular?
If I had to pick out just one, I might actually lean towards mentioning
86dc90056, which might change users' calculus about how many partitions
they can use. (But I may be biased about that.)
My take on that is audience. It's an important feature for existing
users of PostgreSQL, and an important change over how the system
behaved before. They are more likely to read the release notes. The
press release is more about reaching people who are not already using
postgres, or who are so but more tangentially.
Perhaps, but on those grounds, the business about reducing B-tree bloat
doesn't belong in the press release either. Anyway I'm not sure the
audiences are so different --- if I thought they were, I'd not have
started from the press release.
My feeling is that the initial summary in the release notes is meant
to be a 10000-meter overview of what's new in the release. As soon
as you get past that bullet list, you find yourself right down in the
weeds, so an overview is good to have. The press release can afford
to fly a little lower than 10000 meters, though not by all that much.
regards, tom lane
On Wed, Sep 22, 2021 at 2:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Certainly. But my sentence about "Numerous performance improvements"
already mashes down dozens of other it-just-works-better-now
performance improvements. Wny call out that one in particular?
RC 1 is supposed to be released in less than 24 hours. ISTM that we're
almost out of time.
Is some kind of simple compromise possible?
--
Peter Geoghegan
Peter Geoghegan <pg@bowt.ie> writes:
On Wed, Sep 22, 2021 at 2:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Certainly. But my sentence about "Numerous performance improvements"
already mashes down dozens of other it-just-works-better-now
performance improvements. Wny call out that one in particular?
RC 1 is supposed to be released in less than 24 hours. ISTM that we're
almost out of time.
Ummm ... RC1 was wrapped on Monday. It will go out with the "TO BE ADDED"
placeholder for this list. I'm not panicked about time --- we just need
to finalize this text by Sunday-ish.
regards, tom lane
On Wed, Sep 22, 2021 at 7:06 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ummm ... RC1 was wrapped on Monday. It will go out with the "TO BE ADDED"
placeholder for this list. I'm not panicked about time --- we just need
to finalize this text by Sunday-ish.
I assumed that the web team had the discretion to keep the website
version of the release notes a bit more consistent then what you'd get
from the RC1 tarball.
I'm not going to make a fuss about it, but it would have been nice if
we'd kept with the usual schedule for the major features list.
--
Peter Geoghegan
On 9/22/21 10:43 PM, Peter Geoghegan wrote:
On Wed, Sep 22, 2021 at 7:06 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ummm ... RC1 was wrapped on Monday. It will go out with the "TO BE ADDED"
placeholder for this list. I'm not panicked about time --- we just need
to finalize this text by Sunday-ish.I assumed that the web team had the discretion to keep the website
version of the release notes a bit more consistent then what you'd get
from the RC1 tarball.
Nope, they get loaded when the tarball is loaded as part of the release
process.
Jonathan
On Wed, Sep 22, 2021 at 11:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Sep 22, 2021 at 6:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I thought the point about FDWs was important because actual work (by
FDW authors) is needed to make anything happen. The extra parallelism
inside plpgsql functions doesn't require user effort, so I don't see
that it needs to be called out separately.True, but I'm willing to guess we have a lot more people who are using
stored procs with return query and who are going to be very happy
about them now being much faster in cases where parallelism worked,
than we have people who are writing FDWs..Certainly. But my sentence about "Numerous performance improvements"
already mashes down dozens of other it-just-works-better-now
performance improvements. Wny call out that one in particular?
Just my guestimate that that one is going to be one of the more
popular ones. But it is a guess. And I'm not feeling strongly enough
about it to argue that one - if you feel the one there now is more
important,t hen we go with it.
If I had to pick out just one, I might actually lean towards mentioning
86dc90056, which might change users' calculus about how many partitions
they can use. (But I may be biased about that.)
Ah, so you posting that led me to re-read the whole thing again, this
time directly after caffeine.
It starts mentioning parallel query and it finishes with parallel
query. At a quick glance that gave me the impression the whole
paragraph was about "things related to improvements of parallel
query", given how it started.
Knowing that, I'd leave the "numerous improvements for parallel
queries" and just drop the specific mention of FDWs personally. We we
want to call out something in particular at the end, I agree that
86dc90056 is probably a better choice than either of the other two for
being the called-out one.
My take on that is audience. It's an important feature for existing
users of PostgreSQL, and an important change over how the system
behaved before. They are more likely to read the release notes. The
press release is more about reaching people who are not already using
postgres, or who are so but more tangentially.Perhaps, but on those grounds, the business about reducing B-tree bloat
doesn't belong in the press release either. Anyway I'm not sure the
audiences are so different --- if I thought they were, I'd not have
started from the press release.
True on the btree point.
My feeling is that the initial summary in the release notes is meant
to be a 10000-meter overview of what's new in the release. As soon
as you get past that bullet list, you find yourself right down in the
weeds, so an overview is good to have. The press release can afford
to fly a little lower than 10000 meters, though not by all that much.
I'm not really sure of the value of having two different set of
summaries if they're basically targeting the same group. But now is
not the time to bikeshed about the overall structure I think, so I'm
fine keeping it that way. And if that is the target audience then yes,
it makes sense not to have something in the release notes summary
that's not in the press release. I would then argue for *including*
the emergency mode vacuum in the press release.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
On Wed, Sep 22, 2021 at 12:00 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
- Numerous performance ...
- B-tree...
- Subscripting ...
- Range types ...
- Stored ...
- Extended ...
- SEARCH / CYCLE ...
- libpq ...
- TOAST ...
(- emergency mode vacuum ...)
My opinion is that this is awfully long for a list of major features.
But Tom said 10 or so was typical, so perhaps I am all wet.
Still, this kind of seems like a laundry list to me. I'd argue for
cutting range types, extended statistics, SEARCH / CYCLE, TOAST, and
emergency mode vacuum. They're all nice, and I'm glad we have them,
but they're also things that only people who are deeply steeped in
PostgreSQL already seem likely to appreciate. Better scalability, less
bloat, working OUT parameters, and query pipelining have benefits
anyone can understand.
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
Still, this kind of seems like a laundry list to me. I'd argue for
cutting range types, extended statistics, SEARCH / CYCLE, TOAST, and
emergency mode vacuum. They're all nice, and I'm glad we have them,
but they're also things that only people who are deeply steeped in
PostgreSQL already seem likely to appreciate. Better scalability, less
bloat, working OUT parameters, and query pipelining have benefits
anyone can understand.
But of course it's a laundry list, and it's aimed at people steeped
in Postgres, because who else is going to be reading release notes?
Anyway, after re-reading the list, I concur that the TOAST item
shouldn't make the cut, so I took that out along with the explicit
mention of FDWs, and added something about emergency vacuum.
Pushed at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=765f677f364100072160e7af37288eb1df2ff355
regards, tom lane