Thread: 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 thisa 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 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
Attachment
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:
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 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
Attachment
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] 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] https://www.postgresql.org/message-id/c1e72deb-8f8b-694a-1dc1-12ce671f8b8f%40postgresql.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
Attachment
"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 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
Attachment
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
Attachment
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