pgsql: docs: fist draft version of the PG 12 release notes
docs: fist draft version of the PG 12 release notes
Still needs text markup, links, word wrap, and indenting.
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/bdf595adbca195fa54a909c74a5233ebc30641a1
Modified Files
--------------
doc/src/sgml/release-12.sgml | 2842 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 2833 insertions(+), 9 deletions(-)
On Mon, May 6, 2019 at 11:02:37PM +0000, Bruce Momjian wrote:
docs: fist draft version of the PG 12 release notes
Still needs text markup, links, word wrap, and indenting.
You can see the browser version at:
http://momjian.us/tmp/pgsql/release-12.html
I will be away tomorrow/Tuesday but will continue working on this on
Wednesday.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Mon, May 6, 2019 at 07:03:39PM -0400, Bruce Momjian wrote:
On Mon, May 6, 2019 at 11:02:37PM +0000, Bruce Momjian wrote:
docs: fist draft version of the PG 12 release notes
Still needs text markup, links, word wrap, and indenting.
You can see the browser version at:
Sorry, this is a better URL:
http://momjian.us/pgsql_docs/release-12.html
Our official docs will update in a few hours, I assume.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Tue, May 7, 2019 at 5:00 AM Bruce Momjian <bruce@momjian.us> wrote:
On Mon, May 6, 2019 at 07:03:39PM -0400, Bruce Momjian wrote:
On Mon, May 6, 2019 at 11:02:37PM +0000, Bruce Momjian wrote:
docs: fist draft version of the PG 12 release notes
Still needs text markup, links, word wrap, and indenting.
You can see the browser version at:
Sorry, this is a better URL:
Can you please remove below entry from release notes?
Avoid creation of the free space map files for small table (John
Naylor, Amit Kapila)
Such files are not useful.
I have reverted this feature for this release. We might try it for
the next release.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Tue, May 7, 2019 at 11:02 AM Bruce Momjian <bruce@momjian.us> wrote:
https://git.postgresql.org/pg/commitdiff/bdf595adbca195fa54a909c74a5233ebc30641a1
+Use pread() and pwrite() for random I/O (Thomas Munro)
Hi Bruce,
For this one, can we please add Oskari Saarenmaa as first author, and
keep me as second?
--
Thomas Munro
https://enterprisedb.com
"Bruce" == Bruce Momjian <bruce@momjian.us> writes:
Bruce> docs: fist draft version of the PG 12 release notes
Bruce> Still needs text markup, links, word wrap, and indenting.
The floating-point output change probably needs to be called out as a
compatibility issue, not just a performance enhancement.
--
Andrew (irc:RhodiumToad)
Hi Bruce,
On 2019/05/07 8:02, Bruce Momjian wrote:
docs: fist draft version of the PG 12 release notes
Still needs text markup, links, word wrap, and indenting.
Thanks for crafting these up, as always.
About the partitioning performance improvement item:
+<listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2018-11-07 [c6e4133fa] Postpone calculating total_table_pages until after
pruni
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2018-11-15 [34c9e455d] Improve performance of partition pruning remapping
a lit
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2018-11-16 [3f2393ede] Redesign initialization of partition routing
structures
+Author: Robert Haas <rhaas@postgresql.org>
+2019-02-21 [9eefba181] Delay lock acquisition for partitions until we
route a t
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2019-03-30 [428b260f8] Speed up planning when partitions can be pruned at
plan
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2019-04-05 [959d00e9d] Use Append rather than MergeAppend for scanning
ordered
+-->
+
+<para>
+Improve performance of pruning many partitions (Amit Langote, David
Rowley, Tom Lane, Álvaro Herrera)
+</para>
+
+<para>
+Now thousands of partitions can be pruned efficiently.
+</para>
+</listitem>
I think there may be two (or more) distinct improvements here.
* Performance of "pruning" itself which was bottle-necked in the planner
is improved mostly due to:
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2019-03-30 [428b260f8] Speed up planning when partitions can be pruned at
plan
* Also improved is the performance of inserting small number of rows into
partitioned tables which was bottle-necked in the executor because tuple
routing would do some redundant processing per statement. The
improvements are due to:
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+2018-11-16 [3f2393ede] Redesign initialization of partition routing
structures
+Author: Robert Haas <rhaas@postgresql.org>
+2019-02-21 [9eefba181] Delay lock acquisition for partitions until we
route a t
* AFAICT, the following two commits don't seem to have much to do with
improving the performance of pruning, although they are good improvements
in their own right.
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2019-04-05 [959d00e9d] Use Append rather than MergeAppend for scanning
ordered
My summary of this optimization is that with it we can avoid paying the
cost of merging the ordered partition outputs if partitions are determined
to be ordered among themselves (for example, range partitions).
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2018-11-07 [c6e4133fa] Postpone calculating total_table_pages until after
pruni
My summary of this commit is that planner now correctly considers the
effect of partition pruning on cost calculations, whereas previously it
might end up making poor plan choices because it didn't subtract the pages
of pruned partitions from the total_table_pages global counter.
Thanks,
Amit
On Tue, May 7, 2019 at 2:02 AM Bruce Momjian <bruce@momjian.us> wrote:
docs: fist draft version of the PG 12 release notes
Still needs text markup, links, word wrap, and indenting.
"This allows JSON values to be selected using an SQL-standard language."
better
"This allows to execute complex queries on JSON values using an
SQL-standard language."
I think it is a "big item" !
Branch
------
masterDetails
-------
https://git.postgresql.org/pg/commitdiff/bdf595adbca195fa54a909c74a5233ebc30641a1Modified Files
--------------
doc/src/sgml/release-12.sgml | 2842 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 2833 insertions(+), 9 deletions(-)
--
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, May 06, 2019 at 11:02:37PM +0000, Bruce Momjian wrote:
docs: fist draft version of the PG 12 release notes
Still needs text markup, links, word wrap, and indenting.
I have noticed a duplicated word:
$ git grep "new new"
doc/src/sgml/release-12.sgml:Update unaccent rules with new new
punctuation and symbols (Hugh Ranalli, Michael Paquier)
--
Michael
On 2019-May-06, Bruce Momjian wrote:
docs: fist draft version of the PG 12 release notes
Hello, thanks for doing this work once again.
Typo in surname: "Golgov" is Dolgov.
This entry:
Allow foreign keys to reference partitioned tables (Alvaro Herrera)
says "LIMITATIONS?" but I don't think there are any of significance.
You can now reference unique/PKs that appear in partitioned tables,
period. Just remove the LIMITATIONS should do it ;-)
This is a bit misleading:
Remove the special behavior of OID columns (Andres Freund, John Naylor)
Previously, a normally-invisible OID column could be specified
during table creation using WITH OIDS; that ability has been
removed. Columns can still be explicitly specified as type OID.
pg_dump and pg_upgrade operations on databases using WITH OIDS will
need adjustment. Many system tables now have an 'oid' column that
will be expanded with SELECT * by default.
"databases using WITH OIDS will need adjustment". In reality, many
databases carried over by pg_upgrade from old versions will need
adjustment, since old tables had oids by default. This could be more
troublesome than the current wording suggest. Maybe use something like
"... operations on databases containing tables with the oid system
column will need adjustment", so that users have to research whether
they have them or not. If we only say WITH OIDS then people will think
they've never used that clause so they must not worry.
Specify a range of oids (9000-9999) to be used for external
extensions (Andres Freund)
I'm not sure that "specify" is the right verb to use for this one.
Nothing better comes to mind ATM ...
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
------------------------------
<para>
Move recovery.conf settings into postgresql.conf (Fujii Masao, Simon Riggs, Abhijit Menon-Sen, Sergei Kornilov)
</para>
<para>
recovery.conf is no longer used, and recovery.signal and standby.signal are used to switch into non-primary mode.
trigger_file has been renamed to promote_trigger_file. The standby_mode setting has been removed.
</para>
------------------------------
In addition to these, I think it would be better to warn that if
there's a file named "recovery.conf" on stabdby node, postmaster won't
start up:
21909 2019-05-09 07:55:55 JST FATAL: using recovery command file "recovery.conf" is not supported
21907 2019-05-09 07:55:55 JST LOG: startup process (PID 21909) exited with exit code 1
21907 2019-05-09 07:55:55 JST LOG: aborting startup due to startup process failure
21907 2019-05-09 07:55:55 JST LOG: database system is shut down
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
On Tue, May 7, 2019 at 09:44:54AM +0530, Amit Kapila wrote:
On Tue, May 7, 2019 at 5:00 AM Bruce Momjian <bruce@momjian.us> wrote:
On Mon, May 6, 2019 at 07:03:39PM -0400, Bruce Momjian wrote:
On Mon, May 6, 2019 at 11:02:37PM +0000, Bruce Momjian wrote:
docs: fist draft version of the PG 12 release notes
Still needs text markup, links, word wrap, and indenting.
You can see the browser version at:
Sorry, this is a better URL:
Can you please remove below entry from release notes?
Avoid creation of the free space map files for small table (John
Naylor, Amit Kapila)Such files are not useful.
I have reverted this feature for this release. We might try it for
the next release.
Done:
http://momjian.us/pgsql_docs/release-12.html
Sorry for the delay.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Tue, May 7, 2019 at 09:08:06PM +1200, Thomas Munro wrote:
On Tue, May 7, 2019 at 11:02 AM Bruce Momjian <bruce@momjian.us> wrote:
https://git.postgresql.org/pg/commitdiff/bdf595adbca195fa54a909c74a5233ebc30641a1
+Use pread() and pwrite() for random I/O (Thomas Munro)
Hi Bruce,
For this one, can we please add Oskari Saarenmaa as first author, and
keep me as second?
Done:
http://momjian.us/pgsql_docs/release-12.html
Sorry for the delay.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Tue, May 7, 2019 at 02:38:39PM +0100, Andrew Gierth wrote:
"Bruce" == Bruce Momjian <bruce@momjian.us> writes:
Bruce> docs: fist draft version of the PG 12 release notes
Bruce> Still needs text markup, links, word wrap, and indenting.The floating-point output change probably needs to be called out as a
compatibility issue, not just a performance enhancement.
Done:
http://momjian.us/pgsql_docs/release-12.html
Sorry for the delay.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Wed, May 8, 2019 at 10:43:00AM +0900, Amit Langote wrote:
I think there may be two (or more) distinct improvements here.
* Performance of "pruning" itself which was bottle-necked in the planner
is improved mostly due to:+Author: Tom Lane <tgl@sss.pgh.pa.us> +2019-03-30 [428b260f8] Speed up planning when partitions can be pruned at plan* Also improved is the performance of inserting small number of rows into
partitioned tables which was bottle-necked in the executor because tuple
routing would do some redundant processing per statement. The
improvements are due to:+Author: Alvaro Herrera <alvherre@alvh.no-ip.org> +2018-11-16 [3f2393ede] Redesign initialization of partition routing structures +Author: Robert Haas <rhaas@postgresql.org> +2019-02-21 [9eefba181] Delay lock acquisition for partitions until we route a t* AFAICT, the following two commits don't seem to have much to do with
improving the performance of pruning, although they are good improvements
in their own right.+Author: Tom Lane <tgl@sss.pgh.pa.us> +2019-04-05 [959d00e9d] Use Append rather than MergeAppend for scanning orderedMy summary of this optimization is that with it we can avoid paying the
cost of merging the ordered partition outputs if partitions are determined
to be ordered among themselves (for example, range partitions).+Author: Tom Lane <tgl@sss.pgh.pa.us> +2018-11-07 [c6e4133fa] Postpone calculating total_table_pages until after pruniMy summary of this commit is that planner now correctly considers the
effect of partition pruning on cost calculations, whereas previously it
might end up making poor plan choices because it didn't subtract the pages
of pruned partitions from the total_table_pages global counter.
So, in this case, there were so many partitioning improvements, I just
lumped them into one item. I think everyone can consider partitions to
perform much better in PG 12. Is there something more specific we
should communicate here?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Wed, May 8, 2019 at 03:45:34PM +0300, Oleg Bartunov wrote:
On Tue, May 7, 2019 at 2:02 AM Bruce Momjian <bruce@momjian.us> wrote:
docs: fist draft version of the PG 12 release notes
Still needs text markup, links, word wrap, and indenting.
"This allows JSON values to be selected using an SQL-standard language."
better
"This allows to execute complex queries on JSON values using an
SQL-standard language."I think it is a "big item" !
Done:
http://momjian.us/pgsql_docs/release-12.html
Sorry for the delay.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Wed, May 8, 2019 at 10:09:19PM +0900, Michael Paquier wrote:
On Mon, May 06, 2019 at 11:02:37PM +0000, Bruce Momjian wrote:
docs: fist draft version of the PG 12 release notes
Still needs text markup, links, word wrap, and indenting.
I have noticed a duplicated word:
$ git grep "new new"
doc/src/sgml/release-12.sgml:Update unaccent rules with new new
punctuation and symbols (Hugh Ranalli, Michael Paquier)
Fixed:
http://momjian.us/pgsql_docs/release-12.html
Sorry for the delay.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Wed, May 8, 2019 at 04:20:40PM -0400, Alvaro Herrera wrote:
On 2019-May-06, Bruce Momjian wrote:
docs: fist draft version of the PG 12 release notes
Hello, thanks for doing this work once again.
Typo in surname: "Golgov" is Dolgov.
Yes, it was "Golgov" in one commint and "Dolgov" in another; I change
it to "Dolgov".
This entry:
Allow foreign keys to reference partitioned tables (Alvaro Herrera)
says "LIMITATIONS?" but I don't think there are any of significance.
You can now reference unique/PKs that appear in partitioned tables,
period. Just remove the LIMITATIONS should do it ;-)
Done.
This is a bit misleading:
Remove the special behavior of OID columns (Andres Freund, John Naylor)
Previously, a normally-invisible OID column could be specified
during table creation using WITH OIDS; that ability has been
removed. Columns can still be explicitly specified as type OID.
pg_dump and pg_upgrade operations on databases using WITH OIDS will
need adjustment. Many system tables now have an 'oid' column that
will be expanded with SELECT * by default."databases using WITH OIDS will need adjustment". In reality, many
databases carried over by pg_upgrade from old versions will need
adjustment, since old tables had oids by default. This could be more
troublesome than the current wording suggest. Maybe use something like
"... operations on databases containing tables with the oid system
column will need adjustment", so that users have to research whether
they have them or not. If we only say WITH OIDS then people will think
they've never used that clause so they must not worry.
Yes, I reworded it:
http://momjian.us/pgsql_docs/release-12.html
Specify a range of oids (9000-9999) to be used for external
extensions (Andres Freund)I'm not sure that "specify" is the right verb to use for this one.
Nothing better comes to mind ATM ...
I used "Reserve".
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Thu, May 9, 2019 at 07:58:00AM +0900, Tatsuo Ishii wrote:
------------------------------
<para>
Move recovery.conf settings into postgresql.conf (Fujii Masao, Simon Riggs, Abhijit Menon-Sen, Sergei Kornilov)
</para><para>
recovery.conf is no longer used, and recovery.signal and standby.signal are used to switch into non-primary mode.
trigger_file has been renamed to promote_trigger_file. The standby_mode setting has been removed.
</para>
------------------------------In addition to these, I think it would be better to warn that if
there's a file named "recovery.conf" on stabdby node, postmaster won't
start up:21909 2019-05-09 07:55:55 JST FATAL: using recovery command file "recovery.conf" is not supported
21907 2019-05-09 07:55:55 JST LOG: startup process (PID 21909) exited with exit code 1
21907 2019-05-09 07:55:55 JST LOG: aborting startup due to startup process failure
21907 2019-05-09 07:55:55 JST LOG: database system is shut down
Good point, done:
http://momjian.us/pgsql_docs/release-12.html
Sorry for the delay.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Thu, May 9, 2019 at 07:58:00AM +0900, Tatsuo Ishii wrote:
------------------------------
<para>
Move recovery.conf settings into postgresql.conf (Fujii Masao, Simon Riggs, Abhijit Menon-Sen, Sergei Kornilov)
</para><para>
recovery.conf is no longer used, and recovery.signal and standby.signal are used to switch into non-primary mode.
trigger_file has been renamed to promote_trigger_file. The standby_mode setting has been removed.
</para>
------------------------------In addition to these, I think it would be better to warn that if
there's a file named "recovery.conf" on stabdby node, postmaster won't
start up:21909 2019-05-09 07:55:55 JST FATAL: using recovery command file "recovery.conf" is not supported
21907 2019-05-09 07:55:55 JST LOG: startup process (PID 21909) exited with exit code 1
21907 2019-05-09 07:55:55 JST LOG: aborting startup due to startup process failure
21907 2019-05-09 07:55:55 JST LOG: database system is shut downGood point, done:
Confirmed.
Sorry for the delay.
No problem. Thank you!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp