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