Thread: PostgreSQL 13 Beta 1 Release Announcement Draft
Hi, Attached is a draft of the release announcement for the PostgreSQL 13 Beta 1 release this week. The goal of this release announcement is to make people aware of the new features that are introduced in PostgreSQL 13 and, importantly, get them to start testing. I have tried to include a broad array of features that can noticeably impact people's usage of PostgreSQL. Note that the order of the features in the announcement are not in any particular ranking (though I do call out VACUUM as being one of the "most anticipated features"), but are my efforts to try and tell a story about the release. Please let me know your thoughts, comments, corrections, etc. and also if there are any glaring omissions[1]. Please let me know your feedback before the end of Wed. May 20 AOE (i.e. before the release ships). Thanks for your review! Jonathan [1] https://www.postgresql.org/docs/devel/release-13.html
Attachment
On Mon, 2020-05-18 at 22:40 -0400, Jonathan S. Katz wrote: Thanks for the good work! > The `pg_rewind` command also has improvements in PostgreSQL 13. In addition to > `pg_rewind` automatically performing crash recovery, you can now configure use > it to configure standby PostgreSQL instances using the `--write-recovery-conf` > flag. "you can now configure use it" could do with one less verb. Yours, Laurenz Albe
Hi, On 5/18/20 10:40 PM, Jonathan S. Katz wrote: > Hi, > > Attached is a draft of the release announcement for the PostgreSQL 13 > Beta 1 release this week. > > The goal of this release announcement is to make people aware of the new > features that are introduced in PostgreSQL 13 and, importantly, get them > to start testing. I have tried to include a broad array of features that > can noticeably impact people's usage of PostgreSQL. Note that the order > of the features in the announcement are not in any particular ranking > (though I do call out VACUUM as being one of the "most anticipated > features"), but are my efforts to try and tell a story about the release. > > Please let me know your thoughts, comments, corrections, etc. and also > if there are any glaring omissions[1]. Please let me know your feedback > before the end of Wed. May 20 AOE (i.e. before the release ships). > > Thanks for your review! Ditto above^ :) Thanks everyone for your responses (a note on that in a sec). I have attached an update to the release, which will be close to and/or the final copy that goes out tomorrow. Based on the feedback received, I accepted & declined changes based on a) how it impacts our users at large b) if an expression was actually wrong vs. personal preference of explanation. For (a), there is an existing note in the announcement to read the release notes as there may be some features that are more interesting to the reader than what may be described. As mentioned, the goal is to try to have the release announcement as a springboard into what people can use/test. I also received an interesting amount of off-list feedback this iteration. While I generally do not mind chatting (this week an unfortunate exception and I apologize if I did not reply back to you), I do ask as part of the collaborative process to try to keep feedback on list so as to limit duplication of comments. Anyway, I am happy to receive and incorporate additional feedback up until we launch tomorrow ~12 UTC. Thanks! Happy Beta eve :) Jonathan
Attachment
Hello, sorry for the timing on this, but here's some feedback. On 2020-May-20, Jonathan S. Katz wrote: > PostgreSQL 13 introduces many features and improvements to the world's most > advanced open source database. The following is just a small sample of new > features introduced into this latest version of PostgreSQL. "A small sample" suggests to me that there are other equally important features that you did not list, in a somewhat random way. I doubt that's true; as a user, I would expect you to list the most important changes. I would use the phrase "The following are the most visible improvements" or some such. > PostgreSQL 13 adds incremental sorting, which accelerates sorting data when > existing data in a query is already sorted. I'm not sure this is very accurate. I would say "incremental sorting, which can take advantage of partially sorted data". (Could add more to it, "when only a subset of the result set is needed", but that is perhaps too many words). > There are more improvements added to PostgreSQL's partitioning functionality in > this release, including an increased number of cases where a > "partitionwise join" (a join between matching partitions) can be used, I'd say "A join between partitioned tables". (The new feature precisely is that the partition strategies don't have to match exactly anymore). > One of the most anticipated features of PostgreSQL 13 is the ability for the > `VACUUM` command to process indexes in parallel. This functionality can be > accessed using the new `PARALLEL` option on the `VACUUM` command (or > `--parallel` on `vacuumdb`), which allows you to specify the number of parallel > workers to use for vacuuming indexes. Note that this does not work with the > `FULL` option. I feel this "Note" is unnecessary; VACUUM FULL is of fringe use anyway. The phrase on incremental sorting above is better use of these extra words, if you have a surplus. > This release includes more ways to monitor actibity within a PostgreSQL > database: PostgreSQL 13 can now track WAL usage statistics and the progress of > streaming `pg_basebackup`s, and the progress of an `ANALYZE` command. > `pg_basebackup` can also generate a manifest that can be used to verify the > integrity of a backup using a new tool called `pg_verifybackup`. In this monitoring paragraph I would add that it's possible to limit WAL reserved by replication slots. "It is now possible to limit the amount of WAL space reserved by replication slots." Thanks! -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-May-20, Alvaro Herrera wrote: > > PostgreSQL 13 adds incremental sorting, which accelerates sorting data when > > existing data in a query is already sorted. > > I'm not sure this is very accurate. I would say "incremental sorting, > which can take advantage of partially sorted data". (Could add more to > it, "when only a subset of the result set is needed", but that is > perhaps too many words). Rereading my suggestion, it's not super helpful either, as it suggests that it's useful when the data is sorted on disk. I'm coming up with "which can take advantage of sorted results from intermediate query steps to speed up subsequent query steps". Thanks -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 5/20/20 4:30 PM, Alvaro Herrera wrote: > Hello, sorry for the timing on this, but here's some feedback. > > On 2020-May-20, Jonathan S. Katz wrote: > > >> One of the most anticipated features of PostgreSQL 13 is the ability for the >> `VACUUM` command to process indexes in parallel. This functionality can be >> accessed using the new `PARALLEL` option on the `VACUUM` command (or >> `--parallel` on `vacuumdb`), which allows you to specify the number of parallel >> workers to use for vacuuming indexes. Note that this does not work with the >> `FULL` option. > > I feel this "Note" is unnecessary; VACUUM FULL is of fringe use anyway. You would hope so, but given the number of times it shows up on --general I would say the note is important. > The phrase on incremental sorting above is better use of these extra > words, if you have a surplus. > > Thanks! > -- Adrian Klaver adrian.klaver@aklaver.com
On 5/20/20 7:30 PM, Alvaro Herrera wrote: > Hello, sorry for the timing on this, but here's some feedback. > > On 2020-May-20, Jonathan S. Katz wrote: > >> PostgreSQL 13 introduces many features and improvements to the world's most >> advanced open source database. The following is just a small sample of new >> features introduced into this latest version of PostgreSQL. > > "A small sample" suggests to me that there are other equally important > features that you did not list, in a somewhat random way. I doubt > that's true; as a user, I would expect you to list the most important > changes. I would use the phrase "The following are the most visible > improvements" or some such. After trying to reword it, I ended up striking the whole section. A bunch of it was redundant to the above section. The title of the section can have it stand on its own: "PostgreSQL 13 Highlights" >> PostgreSQL 13 adds incremental sorting, which accelerates sorting data when >> existing data in a query is already sorted. > > I'm not sure this is very accurate. I would say "incremental sorting, > which can take advantage of partially sorted data". (Could add more to > it, "when only a subset of the result set is needed", but that is > perhaps too many words). I made modifications based on your downthread comments. >> There are more improvements added to PostgreSQL's partitioning functionality in >> this release, including an increased number of cases where a >> "partitionwise join" (a join between matching partitions) can be used, > > I'd say "A join between partitioned tables". (The new feature precisely > is that the partition strategies don't have to match exactly anymore). Cool, modified. >> One of the most anticipated features of PostgreSQL 13 is the ability for the >> `VACUUM` command to process indexes in parallel. This functionality can be >> accessed using the new `PARALLEL` option on the `VACUUM` command (or >> `--parallel` on `vacuumdb`), which allows you to specify the number of parallel >> workers to use for vacuuming indexes. Note that this does not work with the >> `FULL` option. > > I feel this "Note" is unnecessary; VACUUM FULL is of fringe use anyway. > The phrase on incremental sorting above is better use of these extra > words, if you have a surplus. While I'm not running in production as much as I used to, there will still times I would need to use a VACUUM FULL ;) > >> This release includes more ways to monitor actibity within a PostgreSQL >> database: PostgreSQL 13 can now track WAL usage statistics and the progress of >> streaming `pg_basebackup`s, and the progress of an `ANALYZE` command. >> `pg_basebackup` can also generate a manifest that can be used to verify the >> integrity of a backup using a new tool called `pg_verifybackup`. > > In this monitoring paragraph I would add that it's possible to limit WAL > reserved by replication slots. "It is now possible to limit the amount > of WAL space reserved by replication slots." That is a good one - I added that mostly word-for-word. Thanks! Jonathan