Thread: pg12 release notes
I noticed you added release notes at bdf595adbca195fa54a909c74a5233ebc30641a1, thanks for writing them. I reviewed notes; find proposed changes attached+included. I think these should also be mentioned? f7cb284 Add plan_cache_mode setting a6da004 Add index_get_partition convenience function 387a5cf Add pg_dump --on-conflict-do-nothing option. 17f206f Set pg_class.relhassubclass for partitioned indexes diff --git a/doc/src/sgml/release-12.sgml b/doc/src/sgml/release-12.sgml index 88bdcbd..ab4d1b3 100644 --- a/doc/src/sgml/release-12.sgml +++ b/doc/src/sgml/release-12.sgml @@ -61,8 +61,8 @@ Remove the special behavior of OID columns (Andres Freund, John Naylor) <para> Previously, a normally-invisible OID column could be specified during table creation using WITH OIDS; that ability hasbeen 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 systemtables now have an 'oid' column that will be -expanded with SELECT * by default. +specified as type OID. pg_dump and pg_upgrade operations on databases using WITH OIDS will need adjustment. The 'oid'column of many system tables will be +shown by default with SELECT *. </para> </listitem> @@ -115,7 +115,7 @@ Do not allow multiple different recovery_target* specifications (Peter Eisentrau </para> <para> -Previously multiple different recovery_target* variables could be specified, and last one specified was honored. Now, onlyone can be specified, though the same one can +Previously multiple different recovery_target* variables could be specified, and the last one specified was honored. Now,only one can be specified, though the same one can be specified multiple times and the last specification is honored. </para> </listitem> @@ -405,7 +405,7 @@ Author: Robert Haas <rhaas@postgresql.org> --> <para> -Allow ATTACH PARTITION to be performed with reduced locking requirements (Robert Haas) +ATTACH PARTITION is performed with lower locking requirement (Robert Haas) </para> </listitem> @@ -617,7 +617,7 @@ Have new btree indexes sort duplicate index entries in heap-storage order (Peter </para> <para> -Btree indexes pg_upgraded from previous releases will not have this ordering. This does slightly reduce the maximum lengthof indexed values. +Btree indexes pg_upgraded from previous releases will not have this ordering. This slightly reduces the maximum permittedlength of indexed values. </para> </listitem> @@ -676,7 +676,7 @@ Allow CREATE STATISTICS to create most-common-value statistics for multiple colu </para> <para> -This improve optimization for columns with non-uniform distributions that often appear in WHERE clauses. +This improves query plans for columns with non-uniform distributions that often appear in WHERE clauses. </para> </listitem> @@ -954,21 +954,6 @@ This dramatically speeds up processing of floating-point values. Users who wish <listitem> <!-- -Author: Amit Kapila <akapila@postgresql.org> -2019-02-04 [b0eaa4c51] Avoid creation of the free space map for small heap rela ---> - -<para> -Avoid creation of the free space map files for small table (John Naylor, Amit Kapila) -</para> - -<para> -Such files are not useful. -</para> -</listitem> - -<listitem> -<!-- Author: Thomas Munro <tmunro@postgresql.org> 2018-11-07 [3fd2a7932] Provide pg_pread() and pg_pwrite() for random I/O. Author: Thomas Munro <tmunro@postgresql.org> @@ -1018,7 +1003,7 @@ Allow logging of only a percentage of statements and transactions meeting log_mi </para> <para> -The parameters log_statement_sample_rate and log_transaction_sample_rate controls this. +The parameters log_statement_sample_rate and log_transaction_sample_rate control this. </para> </listitem> @@ -1231,7 +1216,7 @@ Author: Tom Lane <tgl@sss.pgh.pa.us> --> <para> -Allow more comparisons with information_schema text columns use indexes (Tom Lane) +Allow more comparisons with information_schema text columns to use indexes (Tom Lane) </para> </listitem> @@ -1310,7 +1295,7 @@ Author: Thomas Munro <tmunro@postgresql.org> --> <para> -Allow discovery of the LDAP server using DNS (Thomas Munro) +Allow discovery of the LDAP server using DNS SRV records (Thomas Munro) </para> <para> @@ -1446,7 +1431,7 @@ Add wal_recycle and wal_init_zero server variables to avoid WAL file recycling ( </para> <para> -This can be beneficial on copy-on-write file systems like ZFS. +This can be beneficial on copy-on-write filesystems like ZFS. </para> </listitem> @@ -1502,7 +1487,7 @@ Add server variable to control the type of shared memory to use (Andres Freund) </para> <para> -The variable is shared_memory_type. It purpose is to allow selection of System V shared memory, if desired. +The variable is shared_memory_type. Its purpose is to allow selection of System V shared memory, if desired. </para> </listitem>
Attachment
On 2019-May-08, Justin Pryzby wrote: > I noticed you added release notes at bdf595adbca195fa54a909c74a5233ebc30641a1, > thanks for writing them. > > I reviewed notes; find proposed changes attached+included. > > I think these should also be mentioned? > > a6da004 Add index_get_partition convenience function I don't disagree with the other three you suggest, but this one is a C function and I think it's below the level of usefulness that we publish in relnotes. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, May 9, 2019 at 8:32 AM Justin Pryzby <pryzby@telsasoft.com> wrote: > I noticed you added release notes at bdf595adbca195fa54a909c74a5233ebc30641a1, > thanks for writing them. +1 > I reviewed notes; find proposed changes attached+included. +1 to all the corrections shown. One more: "Allow parallel query when in SERIALIZABLE ISOLATION MODE (Thomas Munro)" Only SERIALIZABLE should be in all-caps IMHO. -- Thomas Munro https://enterprisedb.com
On Wed, May 8, 2019 at 03:32:04PM -0500, Justin Pryzby wrote:
> I noticed you added release notes at bdf595adbca195fa54a909c74a5233ebc30641a1,
> thanks for writing them.
> -This improve optimization for columns with non-uniform distributions that often appear in WHERE clauses.
> +This improves query plans for columns with non-uniform distributions that often appear in WHERE clauses.
I think "query plans" is less clear.
> -Author: Amit Kapila <akapila@postgresql.org>
> -2019-02-04 [b0eaa4c51] Avoid creation of the free space map for small heap rela
> --->
> -
> -<para>
> -Avoid creation of the free space map files for small table (John Naylor, Amit Kapila)
> -</para>
> -
> -<para>
> -Such files are not useful.
> -</para>
> -</listitem>
> -
> -<listitem>
> -<!--
Already removed.
> -This can be beneficial on copy-on-write file systems like ZFS.
> +This can be beneficial on copy-on-write filesystems like ZFS.
We usually spell it "file systems" in our docs.
I have made your other changes, with adjustment, patch attached.
The results are here:
http://momjian.us/pgsql_docs/release-12.html
--
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 +
Attachment
On Wed, May 8, 2019 at 03:32:04PM -0500, Justin Pryzby wrote:
> I noticed you added release notes at bdf595adbca195fa54a909c74a5233ebc30641a1,
> thanks for writing them.
>
> I reviewed notes; find proposed changes attached+included.
>
> I think these should also be mentioned?
>
> f7cb284 Add plan_cache_mode setting
> 387a5cf Add pg_dump --on-conflict-do-nothing option.
I am confused how I missed these. There is only one commit between
them, and I suspect I deleted them by accident. I hope those are the
only ones.
> a6da004 Add index_get_partition convenience function
A C function just isn't normally mentioned in the release notes.
> 17f206f Set pg_class.relhassubclass for partitioned indexes
I need help with this one. I know the system column existed in previous
releases, so how is it different now? Do we document system table
changes that are implementation-behavior in the release notes? Usually
we don't.
Applied patch attached, docs updated:
http://momjian.us/pgsql_docs/release-12.html
--
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 +
Attachment
On Thu, May 09, 2019 at 07:35:18PM -0400, Bruce Momjian wrote: > I have made your other changes, with adjustment, patch attached. > > The results are here: > > http://momjian.us/pgsql_docs/release-12.html Thanks > -Many system tables now have an 'oid' column that will be expanded with > -SELECT * by default. > +The many system tables with such columns will now display those columns > +with SELECT * by default. I think "The many" is hard to parse but YMMV. Find attached additional changes from another pass I've made. From 97ddf06bc9221153c52613b8c840409ee698bbad Mon Sep 17 00:00:00 2001 From: Justin Pryzby <pryzbyj@telsasoft.com> Date: Thu, 9 May 2019 14:15:57 -0500 Subject: [PATCH v2 1/2] pg12 relnotes v2 --- doc/src/sgml/release-12.sgml | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/doc/src/sgml/release-12.sgml b/doc/src/sgml/release-12.sgml index ab4d1b3..cc48960 100644 --- a/doc/src/sgml/release-12.sgml +++ b/doc/src/sgml/release-12.sgml @@ -127,7 +127,7 @@ Author: Peter Eisentraut <peter@eisentraut.org> --> <para> -Cause recovery to recover to the latest timeline by default (Peter Eisentraut) +Cause recovery to advance to the latest timeline by default (Peter Eisentraut) </para> <para> @@ -205,7 +205,8 @@ Author: Alvaro Herrera <alvherre@alvh.no-ip.org> --> <para> -Require pg_restore to use "-f -" to output the dump contents to stdout (Euler Taveira) +Require specification of "-f -" to cause pg_restore to write to stdout (Euler +Taveira) </para> <para> @@ -1003,7 +1004,7 @@ Allow logging of only a percentage of statements and transactions meeting log_mi </para> <para> -The parameters log_statement_sample_rate and log_transaction_sample_rate control this. +This is controlled by the new parameters log_statement_sample_rate and log_transaction_sample_rate. </para> </listitem> @@ -1076,7 +1077,7 @@ Add tracking of global objects in system view pg_stat_database (Julien Rouhaud) </para> <para> -The system view row's datoid is reported as zero. +The system wide objects are shown with a datoid of zero. </para> </listitem> @@ -1132,7 +1133,8 @@ Author: Peter Eisentraut <peter@eisentraut.org> --> <para> -Allow viewers of pg_stat_ssl to only see their own rows (Peter Eisentraut) +Restrict visibility of rows in pg_stat_ssl by unprivileged users (Peter +Eisentraut) </para> </listitem> @@ -1216,7 +1218,8 @@ Author: Tom Lane <tgl@sss.pgh.pa.us> --> <para> -Allow more comparisons with information_schema text columns to use indexes (Tom Lane) +Allow use of indexes for more comparisons with text columns of +information_schema (Tom Lane) </para> </listitem> @@ -1280,7 +1283,8 @@ Author: Magnus Hagander <magnus@hagander.net> --> <para> -Allow the clientcert pg_hba.conf option to check the database user name matches the certificate common name (Julian Markwort,Marius Timmer) +Allow the clientcert pg_hba.conf option to check that the database user name +matches the certificate common name (Julian Markwort, Marius Timmer) </para> <para> From f9d2ee1232090d9087f110d3299bdfae3ed2eab9 Mon Sep 17 00:00:00 2001 From: Justin Pryzby <pryzbyj@telsasoft.com> Date: Thu, 9 May 2019 18:50:42 -0500 Subject: [PATCH v2 2/2] Add commas: "Previously," --- doc/src/sgml/release-12.sgml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/src/sgml/release-12.sgml b/doc/src/sgml/release-12.sgml index cc48960..3f9893e 100644 --- a/doc/src/sgml/release-12.sgml +++ b/doc/src/sgml/release-12.sgml @@ -115,7 +115,7 @@ Do not allow multiple different recovery_target* specifications (Peter Eisentrau </para> <para> -Previously multiple different recovery_target* variables could be specified, and the last one specified was honored. Now,only one can be specified, though the same one can +Previously, multiple different recovery_target* variables could be specified, and the last one specified was honored. Now,only one can be specified, though the same one can be specified multiple times and the last specification is honored. </para> </listitem> @@ -183,7 +183,7 @@ Change XML functions like xpath() to never pretty-print their output (Tom Lane) </para> <para> -Previously this happened in some rare cases. ACCURATE? HOW TO GET PRETTY PRINT OUTPUT? +Previously, this happened in some rare cases. ACCURATE? HOW TO GET PRETTY PRINT OUTPUT? </para> </listitem> @@ -384,7 +384,7 @@ Allow partitions bounds to be any expression (Kyotaro Horiguchi, Tom Lane, Amit </para> <para> -Expressions are evaluated at table partitioned table creation time. Previously only constants were allowed as partitionsbounds. +Expressions are evaluated at table partitioned table creation time. Previously, only constants were allowed as partitionsbounds. </para> </listitem> @@ -515,7 +515,7 @@ Allow parallel query when in SERIALIZABLE ISOLATION MODE (Thomas Munro) </para> <para> -Previously parallelism was disabled when in this mode. +Previously, parallelism was disabled when in this mode. </para> </listitem> @@ -793,7 +793,7 @@ Store statistics using the collation defined for each column (Tom Lane) </para> <para> -Previously the default collation was used for all statistics storage. This potentially gives better optimizer behaviorfor columns with non-default collations. +Previously, the default collation was used for all statistics storage. This potentially gives better optimizer behaviorfor columns with non-default collations. </para> </listitem> @@ -1532,7 +1532,7 @@ Allow the streaming replication timeout to be set per connection (Tsunakawa Taka </para> <para> -Previously this could only be set cluster-wide. +Previously, this could only be set cluster-wide. </para> </listitem> @@ -1825,7 +1825,7 @@ Use all column names when creating default foreign key constraint names (Peter E </para> <para> -Previously only the first column name was used. +Previously, only the first column name was used. </para> </listitem> @@ -2329,7 +2329,7 @@ Allow control of log file rotation via pg_ctl (Kyotaro Horiguchi, Alexander Kuzm </para> <para> -Previously this was only possible via an SQL function or a process signal. +Previously, this was only possible via an SQL function or a process signal. </para> </listitem> @@ -2697,7 +2697,7 @@ Properly honor WITH CHECK OPTION on views that reference postgres_fdw tables (Et <para> While CHECK OPTIONs on postgres_fdw tables are ignored (because the reference is foreign), views on such tables are consideredlocal, so this release enforces CHECK -OPTIONs on them. Previously only INSERTs and UPDATEs with RETURNING clauses that returned CHECK OPTION values were validated. +OPTIONs on them. Previously, only INSERTs and UPDATEs with RETURNING clauses that returned CHECK OPTION values were validated. </para> </listitem>
Attachment
On Thu, May 09, 2019 at 08:08:53PM -0400, Bruce Momjian wrote: > On Wed, May 8, 2019 at 03:32:04PM -0500, Justin Pryzby wrote: > > I think these should also be mentioned? > > > > f7cb284 Add plan_cache_mode setting > > 387a5cf Add pg_dump --on-conflict-do-nothing option. > > Applied patch attached, docs updated: Thanks, comments: > +Author: Peter Eisentraut <peter_e@gmx.net> > +2018-07-16 [f7cb2842b] Add plan_cache_mode setting > +--> > + > +<para> > +Allow contol over when generic plans are used for prepared statements (Pavel Stehule) control > +<para> > +The server variable plan_cache_mode enables this control. "This is controlled by the plan_cache_mode parameter". > Author: Tom Lane <tgl@sss.pgh.pa.us> > 2018-12-30 [b5415e3c2] Support parameterized TidPaths. > Author: Tom Lane <tgl@sss.pgh.pa.us> > @@ -2456,6 +2471,21 @@ Add --exclude-database option to pg_dumpall (Andrew Dunstan) > > <listitem> > <!-- > +Author: Thomas Munro <tmunro@postgresql.org> > +2018-07-13 [387a5cfb9] Add pg_dump - -on-conflict-do-nothing option. > +--> > + > +<para> > +Allow restore of INSERT statements to skip rows which would cause conflicts (Surafel Temesgen) > +</para> restore *using* INSERT statements ? cause "unique index" conflicts ? Justin
On Thu, May 9, 2019 at 07:19:59PM -0500, Justin Pryzby wrote:
> > +Author: Thomas Munro <tmunro@postgresql.org>
> > +2018-07-13 [387a5cfb9] Add pg_dump - -on-conflict-do-nothing option.
> > +-->
> > +
> > +<para>
> > +Allow restore of INSERT statements to skip rows which would cause conflicts (Surafel Temesgen)
> > +</para>
>
> restore *using* INSERT statements ?
> cause "unique index" conflicts ?
I am not sure "unique index" helps since most people think of ON
CONFLICT and not its implementation.
Applied patch attached, URL updated:
http://momjian.us/pgsql_docs/build.html
--
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 +
Attachment
On Thu, May 9, 2019 at 07:13:35PM -0500, Justin Pryzby wrote: > On Thu, May 09, 2019 at 07:35:18PM -0400, Bruce Momjian wrote: > > I have made your other changes, with adjustment, patch attached. > > > > The results are here: > > > > http://momjian.us/pgsql_docs/release-12.html > > Thanks These were all very helpful. I adjusted your changes to create the attached applied patch. URL updated: http://momjian.us/pgsql_docs/build.html -- 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 +
Attachment
On Thu, May 09, 2019 at 09:02:51PM -0400, Bruce Momjian wrote: > These were all very helpful. I adjusted your changes to create the > attached applied patch. URL updated: Thanks. > -Allow more comparisons with information_schema text columns to use indexes (Tom Lane) > +Allow more use of indexes for text columns comparisons with information_schema columns (Tom Lane) I think "columns" should not be plural..but it could be better still: |Allow use of indexes for more comparisons with text columns of information_schema (Tom Lane) Regarding this proposed change of mine: -Btree indexes pg_upgraded from previous releases will not have this ordering. This slightly reduces the maximum lengthof indexed values. +Btree indexes pg_upgraded from previous releases will not have this ordering. This slightly reduces the maximum permittedlength of indexed values. I think "permitted" is important, since otherwise it sounds like maybe for whatever values are being indexed, their maximum length is reduced by this patch. If you overthink it, you could decide that maybe that's happening due to use of prefix/suffix truncation or something .. Should this one be listed twice ? I tried to tell if it was intentional but couldn't decide.. 249d64999 Add support TCP user timeout in libpq and the backend se Justin
On Thu, May 9, 2019 at 6:03 PM Bruce Momjian <bruce@momjian.us> wrote: > These were all very helpful. I adjusted your changes to create the > attached applied patch. URL updated: I noticed that the compatibility note for Andrew Gierth's RYU floating point patch seems to simply say why the feature is useful. Shouldn't it be listed separately, and its impact on users upgrading be listed here instead? Separately, please find attached suggested changes for items I was involved in. I have attempted to explain them in a way that makes their relevance to users clearer. Even if you don't end up using my wording, you should still change the attribution along the same lines as the patch. Also, I added a compatibility note for the new version of nbtree, which revises the "1/3 of a page" restriction downwards very slightly (by 8 bytes). FWIW, I think it's very unlikely that anyone will be affected, because tuples that are that wide are already compressed in almost all cases -- it seems like it would be hard to be just at the edge of the limit already. Thanks -- Peter Geoghegan
Attachment
On Fri, 10 May 2019 at 12:08, Bruce Momjian <bruce@momjian.us> wrote: > > 17f206f Set pg_class.relhassubclass for partitioned indexes > > I need help with this one. I know the system column existed in previous > releases, so how is it different now? Do we document system table > changes that are implementation-behavior in the release notes? Usually > we don't. This appears to be fixing something that likely should have been done in PG11, where partitioned indexes were added. Originally the column was for inheritance parent tables, then later used for partitioned tables. It seems partitioned indexes just overlooked setting it to true in PG11 and this commit fixed that. Of course, backpacking that fix wouldn't be very useful for partitioned indexes that were already created, so it was a master only change. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Fri, 10 May 2019 at 13:03, Bruce Momjian <bruce@momjian.us> wrote: > > On Thu, May 9, 2019 at 07:13:35PM -0500, Justin Pryzby wrote: > > On Thu, May 09, 2019 at 07:35:18PM -0400, Bruce Momjian wrote: > > > I have made your other changes, with adjustment, patch attached. > > > > > > The results are here: > > > > > > http://momjian.us/pgsql_docs/release-12.html Hi Bruce, Just a question about the item: "Allow IN comparisons with arrays to use IS NOT NULL partial indexes more frequently (Tom Lane)" From what I can tell this must refer to 65ce07e0202f. If so, I think James Coleman should be the author. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
David Rowley <david.rowley@2ndquadrant.com> writes:
> Just a question about the item: "Allow IN comparisons with arrays to
> use IS NOT NULL partial indexes more frequently (Tom Lane)"
> From what I can tell this must refer to 65ce07e0202f.
You can tell for sure by looking into the SGML comments in
release-12.sgml:
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
2019-02-20 [e04a3905e] Improve planner's understanding of strictness of type co
-->
<para>
Allow IS NOT NULL with mis-matching types to use partial indexes more frequently (Tom Lane)
</para>
> If so, I think James Coleman should be the author.
... and yeah, James should get the credit. But there's more wrong with
the summary than that, because I don't think this was about mismatched
types particularly. The real motivation was to avoid failing to prove
the usability of WHERE-x-IS-NOT-NULL partial indexes for IN clauses with
more than 100 elements.
regards, tom lane
On 2019/05/10 12:18, David Rowley wrote: > On Fri, 10 May 2019 at 12:08, Bruce Momjian <bruce@momjian.us> wrote: >>> 17f206f Set pg_class.relhassubclass for partitioned indexes >> >> I need help with this one. I know the system column existed in previous >> releases, so how is it different now? Do we document system table >> changes that are implementation-behavior in the release notes? Usually >> we don't. > > This appears to be fixing something that likely should have been done > in PG11, where partitioned indexes were added. That's true. We (Michael and I) felt the need to do this change, because it allowed the pg_partition_tree() code (which is also new in v12) to use the same infrastructure for both partitioned tables and indexes; checking the relhassubclass flag allows to short-circuit scanning pg_inherits to find out that there are no children. > Originally the column > was for inheritance parent tables, then later used for partitioned > tables. It seems partitioned indexes just overlooked setting it to > true in PG11 and this commit fixed that. Of course, backpacking that > fix wouldn't be very useful for partitioned indexes that were already > created, so it was a master only change. There was no discussion on whether or not to back-patch this to v11, but the above makes sense. Regarding whether or not this commit needs a release note mention, I'm not that sure but maybe we should if Justin thinks it's useful information. Thanks, Amit
On Fri, 10 May 2019 at 15:45, Tom Lane <tgl@sss.pgh.pa.us> wrote: > <!-- > Author: Tom Lane <tgl@sss.pgh.pa.us> > 2019-02-20 [e04a3905e] Improve planner's understanding of strictness of type co > --> > > <para> > Allow IS NOT NULL with mis-matching types to use partial indexes more frequently (Tom Lane) > </para> > > > If so, I think James Coleman should be the author. > > ... and yeah, James should get the credit. But there's more wrong with > the summary than that, because I don't think this was about mismatched > types particularly. The real motivation was to avoid failing to prove > the usability of WHERE-x-IS-NOT-NULL partial indexes for IN clauses with > more than 100 elements. I think you might be mixing up two items. I'm talking about: <para> Allow IN comparisons with arrays to use <literal>IS NOT NULL</literal> partial indexes more frequently (Tom Lane) </para> to which the sgml references 65ce07e02. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
David Rowley <david.rowley@2ndquadrant.com> writes:
> I think you might be mixing up two items. I'm talking about:
> <para>
> Allow IN comparisons with arrays to use <literal>IS NOT NULL</literal>
> partial indexes more frequently (Tom Lane)
> </para>
> to which the sgml references 65ce07e02.
Wups, sorry, I was talking about 65ce07e02 also, but I managed to
copy-and-paste the wrong bit of release-12.sgml first :-(
regards, tom lane
On Thu, May 09, 2019 at 08:08:53PM -0400, Bruce Momjian wrote: > On Wed, May 8, 2019 at 03:32:04PM -0500, Justin Pryzby wrote: > > I noticed you added release notes at bdf595adbca195fa54a909c74a5233ebc30641a1, > > thanks for writing them. > > > > I reviewed notes; find proposed changes attached+included. > > > > I think these should also be mentioned? > > > > f7cb284 Add plan_cache_mode setting > > 387a5cf Add pg_dump --on-conflict-do-nothing option. > > I am confused how I missed these. There is only one commit between > them, and I suspect I deleted them by accident. I hope those are the > only ones. I'm rechecking my list from last month. What about these ? > c076f3d Remove pg_constraint.conincluding > bd09503 Increase the default vacuum_cost_limit from 200 to 2000 I don't think this one is needed but please check: > 1a990b2 > The API of the function BufFileSize() is changed by this commit, despite Justin
On Fri, May 10, 2019 at 12:45:54PM +0900, Amit Langote wrote: > On 2019/05/10 12:18, David Rowley wrote: > > On Fri, 10 May 2019 at 12:08, Bruce Momjian <bruce@momjian.us> wrote: > >>> 17f206f Set pg_class.relhassubclass for partitioned indexes > >> > >> I need help with this one. I know the system column existed in previous > >> releases, so how is it different now? Do we document system table > >> changes that are implementation-behavior in the release notes? Usually > >> we don't. > > > > This appears to be fixing something that likely should have been done > > in PG11, where partitioned indexes were added. ... > > Originally the column > > was for inheritance parent tables, then later used for partitioned > > tables. It seems partitioned indexes just overlooked setting it to > > true in PG11 and this commit fixed that. Of course, backpacking that > > fix wouldn't be very useful for partitioned indexes that were already > > created, so it was a master only change. ... > Regarding whether or not this commit needs a release note mention, I'm not > that sure but maybe we should if Justin thinks it's useful information. I don't know for sure and I don't feel strongly either way. Last month, I looked through the list of commits to master ([0] rather than using pgsql/src/tools/git_changelog), and made a list of commits I thought should probably be mentioned. I sent to Bruce, in case he could make use of it, and just now triple checked that he'd included all the stuff I could see was important. Added/changed/removed interfaces (programs, libraries, etc), GUCs, catalogs were all on my list (which is what caused me to include index_get_partition, which I agree shouldn't actually be in the relnotes). Behavior changes should sometimes to be there too, but there's internal/implementation changes which shouldn't. Justin [0] git log --oneline --cherry-pick origin/REL_11_STABLE...origin/master On Fri, Apr 12, 2019 at 02:55:38AM -0500, Justin Pryzby wrote: > I was thinking of starting to create release notes ; is it reasonable and > helpful if I put together an initial, 0th order notes document ? > > I just spent a good while identifying the interesting commits from > here...although I'm sure I've missed some. > git log --oneline --cherry-pick origin/REL_11_STABLE...origin/master > > Highlights: > 428b260 Speed up planning when partitions can be pruned at plan time. > f56f8f8 Support foreign keys that reference partitioned tables > 7300a69 Add support for multivariate MCV lists > Progress reporting: > - 03f9e5c Report progress of REINDEX operations > - ab0dfc9 Report progress of CREATE INDEX operations > - 280e5f1 Add progress reporting to pg_checksums > - 6f97457 Add progress reporting for CLUSTER and VACUUM FULL. > > Features: > > \psql: > 1c5d927 psql \dP: list partitioned tables and indexes > 27f3dea psql: Add documentation URL to \help output > 1af25ca Improve psql's \d display of foreign key constraints > d3a5fc1 Show table access methods as such in psql's \dA. > > \GUCs: > 799e220 Log all statements from a sample of transactions > 88bdbd3 Add log_statement_sample_rate parameter > 475861b Add wal_recycle and wal_init_zero GUCs. > f1bebef Add shared_memory_type GUC. > 475861b Add wal_recycle and wal_init_zero GUCs. > f7cb284 Add plan_cache_mode setting > 1a83a80 Allow fractional input values for integer GUCs, and improve rounding logic. > > \Other: > 119dcfa Add vacuum_truncate reloption. > 7bac3ac Add a "SQLSTATE-only" error verbosity option to libpq and psql. > ea569d6 Add SETTINGS option to EXPLAIN, to print modified settings. > b0b39f7 GSSAPI encryption support > fc22b66 Generated columns > 5dc92b8 REINDEX CONCURRENTLY > 8edd0e7 Suppress Append and MergeAppend plan nodes that have a single child. > 280a408 Transaction chaining > ed308d7 Add options to enable and disable checksums in pg_checksums > 0f086f8 Add DNS SRV support for LDAP server discovery. > dd299df Make heap TID a tiebreaker nbtree index column. > => and others > 01bde4f Implement OR REPLACE option for CREATE AGGREGATE. > 72b6460 Partial implementation of SQL/JSON path language > c6c9474 Use condition variables to wait for checkpoints. > f2e4038 Support for INCLUDE attributes in GiST indexes > 6b9e875 Track block level checksum failures in pg_stat_database > 898e5e3 Allow ATTACH PARTITION with only ShareUpdateExclusiveLock. > 7e413a0 pg_dump: allow multiple rows per insert > 8586bf7 tableam: introduce table AM infrastructure. > ac88d29 Avoid creation of the free space map for small heap relations. > 31f3817 Allow COPY FROM to filter data using WHERE conditions > 6260cc5 pgbench: add \cset and \gset commands > ca41030 Fix tablespace handling for partitioned tables > aa2ba50 Add CSV table output mode in psql. > 2dedf4d Integrate recovery.conf into postgresql.conf > 578b229 Remove WITH OIDS support, change oid catalog column visibility. > 9ccdd7f PANIC on fsync() failure. > 803b130 Add option SKIP_LOCKED to VACUUM and ANALYZE > ec74369 Implement "pg_ctl logrotate" command > > Interfaces: > b96f6b1 pg_partition_ancestors > a6da004 Add index_get_partition convenience function > f1d85aa Add support for hyperbolic functions, as well as log10(). > 3677a0b Add pg_partition_root to display top-most parent of a partition tree > d5eec4e Add pg_partition_tree to display information about partitions > 1007465 Add pg_promote function > c481016 Add pg_ls_archive_statusdir function > 9cd92d1 Add pg_ls_tmpdir function > > 2970afa Add PQresultMemorySize function to report allocated size of a PGresult. > > 00d1e88 Add --min-xid-age and --min-mxid-age options to vacuumdb > 354e95d Add --disable-page-skipping and --skip-locked to vacuumdb > 2d34ad8 Add a --socketdir option to pg_upgrade. > 387a5cf Add pg_dump --on-conflict-do-nothing option. > 8a00b96 Add pg_rewind --no-sync > e0090c8 Add option -N/--no-sync to pg_checksums > f092de0 Add --exclude-database option to pg_dumpall > > 17f206f Set pg_class.relhassubclass for partitioned indexes > f94cec6 Include partitioned indexes to system view pg_indexes > b13a913 Add BKI_DEFAULT to pg_class.relrewrite > > 7fee252 Add timestamp of last received message from standby to pg_stat_replication > f60a0e9 Add more columns to pg_stat_ssl > 43cbeda Extend pg_stat_statements_reset to reset statistics specific to a particular user/db/query. > > grep for pg_ Add|remove|move|Compat|Break|Release|pq|--|\ > API pg_ > \.c \.h > v1 > > Compat: > 6dd263c Rename pg_verify_checksums to pg_checksums > 342cb65 Don't log incomplete startup packet if it's empty > 6ae578a Set fallback_application_name for a walreceiver to cluster_name > 689d15e Log PostgreSQL version number on startup > XXX 478cacb Ensure consistent name matching behavior in processSQLNamePattern(). > bcbd940 Remove dynamic_shared_memory_type=none > cda6a8d Remove deprecated abstime, reltime, tinterval datatypes. > 2d10def Remove timetravel extension. > 96b00c4 Remove obsolete pg_constraint.consrc column > fe50382 Remove obsolete pg_attrdef.adsrc column > c076f3d Remove pg_constraint.conincluding > dd299df > The maximum allowed size of new tuples is reduced by an amount equal to > the space required to store an extra MAXALIGN()'d TID in a new high key > during leaf page splits. The user-facing definition of the "1/3 of a > page" restriction is already imprecise, and so does not need to be > revised. However, there should be a compatibility note in the v12 > release notes. > 1a990b2 > The API of the function BufFileSize() is changed by this commit, despite > cbccac3 Reduce the default value of autovacuum_vacuum_cost_delay to 2ms. > bd09503 Increase the default vacuum_cost_limit from 200 to 2000 > 413ccaa pg_restore: Require "-f -" to mean stdout > > Perform: > fe28069 Scan GiST indexes in physical order during VACUUM. > c24dcd0 Use pg_pread() and pg_pwrite() for data files and WAL. > 0d5f05c Allow multi-inserts during COPY into a partitioned table > 959d00e Use Append rather than MergeAppend for scanning ordered partitions. > bbb96c3 Allow ALTER TABLE .. SET NOT NULL to skip provably unnecessary scans. > 3c59263 Avoid some table rewrites for ALTER TABLE .. SET DATA TYPE timestamp. > 3a769d8 pg_upgrade: Allow use of file cloning > bb16aba Enable parallel query with SERIALIZABLE isolation. > 2a63683 Add support for nearest-neighbor (KNN) searches to SP-GiST > > Source: > d9dd406 Require C99 (and thus MSCV 2013 upwards). > > Bugs: > 036f7d3 Avoid counting transaction stats for parallel worker cooperating transaction. > ? 251cf2e Fix minor deficiencies in XMLTABLE, xpath(), xmlexists()
On Fri, 10 May 2019 at 16:52, Justin Pryzby <pryzby@telsasoft.com> wrote: > I'm rechecking my list from last month. What about these ? > > > c076f3d Remove pg_constraint.conincluding > > bd09503 Increase the default vacuum_cost_limit from 200 to 2000 bd09503 was reverted in 52985e4fea7 and replaced by cbccac371, which is documented already by: <para> Reduce the default value of <varname>autovacuum_vacuum_cost_delay</varname> to 2ms (Tom Lane) </para> -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Fri, 10 May 2019 at 16:57, Justin Pryzby <pryzby@telsasoft.com> wrote: > > 8edd0e7 Suppress Append and MergeAppend plan nodes that have a single child. You could say that I'm biased, but I think this should get a mention. It's not just a matter of tidying up the plan by getting rid of nodes that are not requires, it allows plan shapes that were not possible before, for example, a parallel index scan on the index of a partition and the ability to not needlessly include a Materialize node in a Merge Join or Nested Loop Join to a partitioned table, when only 1 partition survives pruning. I'd say wording along the lines of: * Allow the optimizer to no longer generate plans containing a single sub-node Append/MergeAppend node. This allows more plan types to be considered. [...] > > Perform: > > 959d00e Use Append rather than MergeAppend for scanning ordered partitions. I also think this is worth a mention. The speedup can be quite large when the query involves a LIMIT clause, and I think it will apply fairly often. Most of the times I've seen partitioned table the wild they were RANGE partitioned by a timestamp, or at least they were inheritance based tables partitioned by timestamp that could one day be changed to a RANGE partitioned table. I'd say something like: * Allow the optimizer to exploit the ordering of RANGE and LIST partitioned tables when generating paths for partitioned tables. This saves the optimizer from using MergeAppend node to scan a partitioned table in order when an Append node will do. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Hi David, On 2019/05/10 14:51, David Rowley wrote: > On Fri, 10 May 2019 at 16:57, Justin Pryzby <pryzby@telsasoft.com> wrote: >>> 959d00e Use Append rather than MergeAppend for scanning ordered partitions. > > I also think this is worth a mention. The speedup can be quite large > when the query involves a LIMIT clause, and I think it will apply > fairly often. Most of the times I've seen partitioned table the wild > they were RANGE partitioned by a timestamp, or at least they were > inheritance based tables partitioned by timestamp that could one day > be changed to a RANGE partitioned table. > > I'd say something like: > > * Allow the optimizer to exploit the ordering of RANGE and LIST > partitioned tables when generating paths for partitioned tables. > > This saves the optimizer from using MergeAppend node to scan a > partitioned table in order when an Append node will do. FWIW, I've asked [1] Bruce to mention this commit in its own release note item. Currently, it's buried under pruning performance improvement item, like this. <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> Thanks, Amit [1] https://www.postgresql.org/message-id/3f0333be-fd32-55f2-9817-5853a6bbd233%40lab.ntt.co.jp
On 2019-May-10, Amit Langote wrote: > On 2019/05/10 12:18, David Rowley wrote: > > On Fri, 10 May 2019 at 12:08, Bruce Momjian <bruce@momjian.us> wrote: > >>> 17f206f Set pg_class.relhassubclass for partitioned indexes > >> > >> I need help with this one. I know the system column existed in previous > >> releases, so how is it different now? Do we document system table > >> changes that are implementation-behavior in the release notes? Usually > >> we don't. I very much doubt that the change is relevant to the release notes. > > This appears to be fixing something that likely should have been done > > in PG11, where partitioned indexes were added. > > That's true. We (Michael and I) felt the need to do this change, because > it allowed the pg_partition_tree() code (which is also new in v12) to use > the same infrastructure for both partitioned tables and indexes; checking > the relhassubclass flag allows to short-circuit scanning pg_inherits to > find out that there are no children. I'm of two minds about backpatching that fix. In pg12 it makes sense to have the fix, to allow the SRF functions to work correctly. Since we don't use that flag for partitioned indexes anywhere in the backend in pg11, it seems pretty useless to have it there. On the other hand, if any user tool is inspecting catalogs, it might fail to point out descendants for partitioned indexes, if the user asked for a report... but frankly I doubt there are any tools that do that, or users that care for such a report, or even that that report exist ... and even if that report existed, I doubt that it would optimize out the read of pg_inherits by checking relhassubclass beforehand. Still, it's an inconsistency in pg11. I vote -0 to getting it backpatched, mostly because it seems like more work than is warranted. (I think the work consists not only of testing that the backpatched commit works correctly, but also documenting for 11.4 release notes how to fix existing catalogs after upgrading.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Still, it's an inconsistency in pg11. I vote -0 to getting it
> backpatched, mostly because it seems like more work than is warranted.
> (I think the work consists not only of testing that the backpatched
> commit works correctly, but also documenting for 11.4 release notes how
> to fix existing catalogs after upgrading.)
Yeah, I agree. Even if we back-patched a code change, nothing could
rely on relhassubclass for this purpose in a v11 database, because
of not knowing whether the user actually bothered to manually update
pre-existing indexes' entries. Better to know that it doesn't work
than to be unsure if it does.
regards, tom lane
On Thu, May 9, 2019 at 08:34:49PM -0500, Justin Pryzby wrote: > On Thu, May 09, 2019 at 09:02:51PM -0400, Bruce Momjian wrote: > > These were all very helpful. I adjusted your changes to create the > > attached applied patch. URL updated: > > Thanks. > > > -Allow more comparisons with information_schema text columns to use indexes (Tom Lane) > > +Allow more use of indexes for text columns comparisons with information_schema columns (Tom Lane) > > I think "columns" should not be plural..but it could be better still: I now realize "columns" is not necessary, so I removed it. > |Allow use of indexes for more comparisons with text columns of information_schema (Tom Lane) > > Regarding this proposed change of mine: > -Btree indexes pg_upgraded from previous releases will not have this ordering. This slightly reduces the maximum lengthof indexed values. > +Btree indexes pg_upgraded from previous releases will not have this ordering. This slightly reduces the maximum permittedlength of indexed values. > > I think "permitted" is important, since otherwise it sounds like maybe for > whatever values are being indexed, their maximum length is reduced by this > patch. If you overthink it, you could decide that maybe that's happening due > to use of prefix/suffix truncation or something .. Agreed. I changed it to "maximum-allowed length". I also reordered the paragraph. > Should this one be listed twice ? I tried to tell if it was intentional but > couldn't decide.. > 249d64999 Add support TCP user timeout in libpq and the backend se One is a server variable, the other a libpq option. Applied patch attached. -- 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 +
Attachment
On Thu, May 9, 2019 at 07:10:43PM -0700, Peter Geoghegan wrote:
> On Thu, May 9, 2019 at 6:03 PM Bruce Momjian <bruce@momjian.us> wrote:
> > These were all very helpful. I adjusted your changes to create the
> > attached applied patch. URL updated:
>
> I noticed that the compatibility note for Andrew Gierth's RYU floating
> point patch seems to simply say why the feature is useful. Shouldn't
> it be listed separately, and its impact on users upgrading be listed
> here instead?
The text is now in the incompatibility section:
http://momjian.us/pgsql_docs/release-12.html
Avoid performing unnecessary rounding of REAL and DOUBLE PRECISION
values (Andrew Gierth)
This dramatically speeds up processing of floating-point values, though
trailing digits are display slightly differently. Users who wish to have
------------------------------------------------
output that is rounded can set extra_float_digits=0.
Do I need more?
> Separately, please find attached suggested changes for items I was
> involved in. I have attempted to explain them in a way that makes
> their relevance to users clearer. Even if you don't end up using my
> wording, you should still change the attribution along the same lines
> as the patch.
>
> Also, I added a compatibility note for the new version of nbtree,
> which revises the "1/3 of a page" restriction downwards very slightly
> (by 8 bytes). FWIW, I think it's very unlikely that anyone will be
> affected, because tuples that are that wide are already compressed in
> almost all cases -- it seems like it would be hard to be just at the
> edge of the limit already.
I have that:
Have new btree indexes sort duplicate index entries in heap-storage
order (Peter Geoghegan)
This slightly reduces the maximum-allowed length of indexed values.
-------------------------------------------------------------------
Indexes pg_upgraded from previous releases will not have this ordering.
I don't think more details are really needed.
> +</listitem>
> +
> +<listitem>
> +<!--
> +Author: Peter Geoghegan <pg@bowt.ie>
> +2019-03-20 [dd299df8] Make heap TID a tiebreaker nbtree index column.
> +-->
> +
> +<para>
> + Lower the limit on the size of new B-tree index tuples by 8 bytes
> + (Peter Geoghegan)
> +</para>
> +
> +<para>
> + The definition of the "1/3 of a page" restriction on new B-tree
> + entries has been revised to account for the possible overhead of
> + storing table TIDs in branch page keys. Indexes in databases that
> + are migrated using pg_upgrade are not affected, unless and until
> + they are reindexed.
> +</para>
> </listitem>
See above, already mentioned.
> -Improve speed of btree index insertions (Alexander Korotkov, Peter Geoghegan)
> + Don't re-lock B-Tree leaf pages while inserting a new entry (Alexander Korotkov)
What we have already seems like enough detail:
Improve speed of btree index insertions (Alexander Korotkov,
Peter Geoghegan)
Locking speed seems like an implementation detail.
> +<para>
> + Make B-tree index keys unique by treating table TID as a tiebreaker
> + column internally (Peter Geoghegan, Heikki Linnakangas)
> </para>
>
> <para>
> - LOOKUP, INDEX CLEANUP IMPROVEMENTS?
> + The new approach has more predictable performance characteristics
> + with indexes that have many duplicate entries, particularly when
> + there are <command>DELETE</command>s or <command>UPDATE</command>s
> + that affect a large number of contiguous table rows.
You have given me very good detail, so the new text is:
Improve speed of btree index insertions (Alexander Korotkov, Peter
Geoghegan)
The new code improves the space-efficiency of page splits, reduces
locking
overhead, and gives better performance for <command>UPDATE</command>s
and <command>DELETE</command>s on indexes with many duplicates.
> +<para>
> + Make more sophisticated decisions about where to split B-tree pages
> + (Peter Geoghegan)
> +</para>
> +
> +<para>
> + The algorithm for choosing B-tree split points now considers the
> + overall pattern of how new entries are inserted, which can result in
> + more free space being available where it is likely to be needed.
> </para>
> </listitem>
See above.
> -<para>
> -Have new btree indexes sort duplicate index entries in heap-storage order (Peter Geoghegan)
> -</para>
> -
> -<para>
> -Btree indexes pg_upgraded from previous releases will not have this ordering. This slightly reduces the maximum
lengthof indexed values.
> -</para>
> -</listitem>
See above.
--
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 Fri, May 10, 2019 at 03:34:15PM +1200, David Rowley wrote: > On Fri, 10 May 2019 at 13:03, Bruce Momjian <bruce@momjian.us> wrote: > > > > On Thu, May 9, 2019 at 07:13:35PM -0500, Justin Pryzby wrote: > > > On Thu, May 09, 2019 at 07:35:18PM -0400, Bruce Momjian wrote: > > > > I have made your other changes, with adjustment, patch attached. > > > > > > > > The results are here: > > > > > > > > http://momjian.us/pgsql_docs/release-12.html > > Hi Bruce, > > Just a question about the item: "Allow IN comparisons with arrays to > use IS NOT NULL partial indexes more frequently (Tom Lane)" > > >From what I can tell this must refer to 65ce07e0202f. If so, I think > James Coleman should be the author. You are 100% correct, my apologies, fixed. -- 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 Fri, May 10, 2019 at 6:02 PM Bruce Momjian <bruce@momjian.us> wrote: > Have new btree indexes sort duplicate index entries in heap-storage > order (Peter Geoghegan) > > This slightly reduces the maximum-allowed length of indexed values. > ------------------------------------------------------------------- > Indexes pg_upgraded from previous releases will not have this ordering. > > I don't think more details are really needed. Whether or not you include more details is not what I care about here -- I *agree* that this is insignificant. I think that the maximum allowed length thing should be listed in the compatibility section as a formality -- not alongside the point that the feature is listed. I had better be correct in that general assessment, because it's not possible to opt out of the restriction within CREATE INDEX. That was my point here. > What we have already seems like enough detail: > > Improve speed of btree index insertions (Alexander Korotkov, > Peter Geoghegan) Why? I think that it's unfortunate that Heikki wasn't given an authorship credit here, as proposed in my patch. I think that he deserves it. > Locking speed seems like an implementation detail. They're all implementations details, though. If that was the actual standard, then few or no "indexing" items would be listed. > You have given me very good detail, so the new text is: > > Improve speed of btree index insertions (Alexander Korotkov, Peter > Geoghegan) > > The new code improves the space-efficiency of page splits, reduces > locking > overhead, and gives better performance for <command>UPDATE</command>s > and <command>DELETE</command>s on indexes with many duplicates. I can live with that. I'm not trying to be difficult -- reasonable people can disagree on the level of detail that is appropriate (they can even have radically different ideas about where to draw the line). And, I would expect it to be a little arbitrary under the best of circumstances, no matter who was tasked with writing the release notes. However, I think the process would be easier and more effective if you took more time to understand the concerns behind the feedback you get. There are sometimes important nuances. As things stand, I feel like the question of authorship and credit complicates the question of making the release notes useful, which is unfortunate. (Not sure what can be done about that.) -- Peter Geoghegan
>>>>> "Bruce" == Bruce Momjian <bruce@momjian.us> writes: >> I noticed that the compatibility note for Andrew Gierth's RYU >> floating point patch seems to simply say why the feature is useful. >> Shouldn't it be listed separately, and its impact on users upgrading >> be listed here instead? Bruce> The text is now in the incompatibility section: Bruce> http://momjian.us/pgsql_docs/release-12.html Bruce> Avoid performing unnecessary rounding of REAL and DOUBLE PRECISION Bruce> values (Andrew Gierth) Bruce> This dramatically speeds up processing of floating-point values, though Bruce> trailing digits are display slightly differently. Users who wish to have Bruce> ------------------------------------------------ Bruce> output that is rounded can set extra_float_digits=0. Bruce> Do I need more? That isn't quite how I'd have worded it, but I'm not sure what the best wording is. Something like: * Output REAL and DOUBLE PRECISION values in shortest-exact format by default, and change the behavior of extra_float_digits Previously, float values were output rounded to 6 or 15 decimals by default, with the number of decimals adjusted by extra_float_digits. The previous rounding behavior is no longer the default, and is now done only if extra_float_digits is set to zero or less; if the value is greater than zero (which it is by default), a shortest-precise representation is output (for a substantial performance improvement). This representation preserves the exact binary value when correctly read back in, even though the trailing digits will usually differ from the output generated by previous versions when extra_float_digits=3. But I'm not 100% happy with this wording and am entirely open to suggestions for improvement. (In passing I've spotted some related typos in the body of the docs which are probably my fault, I'll fix those.) -- Andrew (irc:RhodiumToad)
On Fri, May 10, 2019 at 06:53:55PM -0700, Peter Geoghegan wrote: > On Fri, May 10, 2019 at 6:02 PM Bruce Momjian <bruce@momjian.us> wrote: > > Have new btree indexes sort duplicate index entries in heap-storage > > order (Peter Geoghegan) > > > > This slightly reduces the maximum-allowed length of indexed values. > > ------------------------------------------------------------------- > > Indexes pg_upgraded from previous releases will not have this ordering. > > > > I don't think more details are really needed. > > Whether or not you include more details is not what I care about here > -- I *agree* that this is insignificant. > > I think that the maximum allowed length thing should be listed in the > compatibility section as a formality -- not alongside the point that > the feature is listed. I had better be correct in that general > assessment, because it's not possible to opt out of the restriction > within CREATE INDEX. That was my point here. Well, we can move the entire item up to the incompatibility section, but that seems unbalanced since the incompatibility is so small relative to the entire item, and it is rare, as you mentioned. It also seems odd to create a stand-alone incompatibility item that really is part of a later item already in the release notes. > > What we have already seems like enough detail: > > > > Improve speed of btree index insertions (Alexander Korotkov, > > Peter Geoghegan) > > Why? > > I think that it's unfortunate that Heikki wasn't given an authorship > credit here, as proposed in my patch. I think that he deserves it. I did not notice that change. I have added him. > > Locking speed seems like an implementation detail. > > They're all implementations details, though. If that was the actual > standard, then few or no "indexing" items would be listed. > > > You have given me very good detail, so the new text is: > > > > Improve speed of btree index insertions (Alexander Korotkov, Peter > > Geoghegan) > > > > The new code improves the space-efficiency of page splits, reduces > > locking > > overhead, and gives better performance for <command>UPDATE</command>s > > and <command>DELETE</command>s on indexes with many duplicates. > > I can live with that. > > I'm not trying to be difficult -- reasonable people can disagree on > the level of detail that is appropriate (they can even have radically > different ideas about where to draw the line). And, I would expect it > to be a little arbitrary under the best of circumstances, no matter > who was tasked with writing the release notes. However, I think the > process would be easier and more effective if you took more time to > understand the concerns behind the feedback you get. There are > sometimes important nuances. I think I have understood the nuances, as listed above --- I just don't agree with the solution. > As things stand, I feel like the question of authorship and credit > complicates the question of making the release notes useful, which is > unfortunate. (Not sure what can be done about that.) That part I always need big help with, particularly with multiple commits being lumped into a single release note entry. I just can't tell which commit is more important when knowing what order to list the names. I have that problem big-time with the partition commits. -- 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 Fri, May 10, 2019 at 7:11 PM Bruce Momjian <bruce@momjian.us> wrote: > > Whether or not you include more details is not what I care about here > > -- I *agree* that this is insignificant. > Well, we can move the entire item up to the incompatibility section, but > that seems unbalanced since the incompatibility is so small relative to > the entire item, and it is rare, as you mentioned. It also seems odd to > create a stand-alone incompatibility item that really is part of a later > item already in the release notes. That is what we've always done. The list has always been very long, with individual items that are on average totally insignificant. Breaking with that pattern in this instance will be confusing to users. > I think I have understood the nuances, as listed above --- I just don't > agree with the solution. To be clear, I don't expect you to agree with the solution. Another thing that you missed from my patch is that bugfix commit 9b10926263d831fac5758f1493c929a49b55669b shouldn't be listed. > > As things stand, I feel like the question of authorship and credit > > complicates the question of making the release notes useful, which is > > unfortunate. (Not sure what can be done about that.) > > That part I always need big help with, particularly with multiple > commits being lumped into a single release note entry. I just can't > tell which commit is more important when knowing what order to list the > names. I have that problem big-time with the partition commits. I understand that it's a difficult job. It's inevitable that there will need to be corrections. You don't appear to be particularly receptive to feedback, which makes the process harder for everyone -- even in instances where you make the right call. I don't think that I am alone in seeing it this way. -- Peter Geoghegan
On Sat, May 11, 2019 at 03:06:40AM +0100, Andrew Gierth wrote:
> >>>>> "Bruce" == Bruce Momjian <bruce@momjian.us> writes:
> Bruce> Do I need more?
>
> That isn't quite how I'd have worded it, but I'm not sure what the best
> wording is. Something like:
>
> * Output REAL and DOUBLE PRECISION values in shortest-exact format by
> default, and change the behavior of extra_float_digits
>
> Previously, float values were output rounded to 6 or 15 decimals by
> default, with the number of decimals adjusted by extra_float_digits.
> The previous rounding behavior is no longer the default, and is now
> done only if extra_float_digits is set to zero or less; if the value
> is greater than zero (which it is by default), a shortest-precise
> representation is output (for a substantial performance improvement).
> This representation preserves the exact binary value when correctly
> read back in, even though the trailing digits will usually differ
> from the output generated by previous versions when
> extra_float_digits=3.
>
> But I'm not 100% happy with this wording and am entirely open to
> suggestions for improvement.
I went with this paragraph:
This dramatically speeds up processing of floating-point values but
causes additional trailing digits to potentially be displayed. Users
wishing to have output that is rounded to match the previous behavior
can set <literal>extra_float_digits=0</literal>, which is no longer the
default.
Improvements?
--
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 Fri, May 10, 2019 at 07:31:21PM -0700, Peter Geoghegan wrote: > On Fri, May 10, 2019 at 7:11 PM Bruce Momjian <bruce@momjian.us> wrote: > > > Whether or not you include more details is not what I care about here > > > -- I *agree* that this is insignificant. > > > Well, we can move the entire item up to the incompatibility section, but > > that seems unbalanced since the incompatibility is so small relative to > > the entire item, and it is rare, as you mentioned. It also seems odd to > > create a stand-alone incompatibility item that really is part of a later > > item already in the release notes. > > That is what we've always done. The list has always been very long, > with individual items that are on average totally insignificant. > Breaking with that pattern in this instance will be confusing to > users. I have no idea what you are suggesting above. > > I think I have understood the nuances, as listed above --- I just don't > > agree with the solution. > > To be clear, I don't expect you to agree with the solution. > > Another thing that you missed from my patch is that bugfix commit > 9b10926263d831fac5758f1493c929a49b55669b shouldn't be listed. Why should it not be listed? -- 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 Sat, May 11, 2019 at 10:36:13AM -0400, Bruce Momjian wrote: > On Fri, May 10, 2019 at 07:31:21PM -0700, Peter Geoghegan wrote: > > > I think I have understood the nuances, as listed above --- I just don't > > > agree with the solution. > > > > To be clear, I don't expect you to agree with the solution. > > > > Another thing that you missed from my patch is that bugfix commit > > 9b10926263d831fac5758f1493c929a49b55669b shouldn't be listed. > > Why should it not be listed? Thinking some more, I try to aggregate all the feature addition commits together, but often skip "cleanups" of previous feature additions. Are you saying that 9b10926263d831fac5758f1493c929a49b55669b is a cleanup, and not part of the feature addition? It was not clear to me of 9b10926263d831fac5758f1493c929a49b55669b was a further enhancement made possible by previous commits, or a "fix" for a previous commit. -- 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 Sat, May 11, 2019 at 7:40 AM Bruce Momjian <bruce@momjian.us> wrote: > > > > I think I have understood the nuances, as listed above --- I just don't > > > > agree with the solution. > > > > > > To be clear, I don't expect you to agree with the solution. > > > > > > Another thing that you missed from my patch is that bugfix commit > > > 9b10926263d831fac5758f1493c929a49b55669b shouldn't be listed. > > > > Why should it not be listed? > > Thinking some more, I try to aggregate all the feature addition commits > together, but often skip "cleanups" of previous feature additions. Are > you saying that 9b10926263d831fac5758f1493c929a49b55669b is a cleanup, > and not part of the feature addition? It was not clear to me of > 9b10926263d831fac5758f1493c929a49b55669b was a further enhancement > made possible by previous commits, or a "fix" for a previous commit. Yes. It's a bug fix that went in after feature freeze. -- Peter Geoghegan
On Sat, May 11, 2019 at 10:28:08AM -0700, Peter Geoghegan wrote: > On Sat, May 11, 2019 at 7:40 AM Bruce Momjian <bruce@momjian.us> wrote: > > > > > I think I have understood the nuances, as listed above --- I just don't > > > > > agree with the solution. > > > > > > > > To be clear, I don't expect you to agree with the solution. > > > > > > > > Another thing that you missed from my patch is that bugfix commit > > > > 9b10926263d831fac5758f1493c929a49b55669b shouldn't be listed. > > > > > > Why should it not be listed? > > > > Thinking some more, I try to aggregate all the feature addition commits > > together, but often skip "cleanups" of previous feature additions. Are > > you saying that 9b10926263d831fac5758f1493c929a49b55669b is a cleanup, > > and not part of the feature addition? It was not clear to me of > > 9b10926263d831fac5758f1493c929a49b55669b was a further enhancement > > made possible by previous commits, or a "fix" for a previous commit. > > Yes. It's a bug fix that went in after feature freeze. OK, commit removed. -- 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 Sat, May 11, 2019 at 11:02 AM Bruce Momjian <bruce@momjian.us> wrote: > OK, commit removed. You're mistaken -- nothing has been pushed to master in the last 3 hours. -- Peter Geoghegan
On Sat, May 11, 2019 at 11:47:42AM -0700, Peter Geoghegan wrote: > On Sat, May 11, 2019 at 11:02 AM Bruce Momjian <bruce@momjian.us> wrote: > > OK, commit removed. > > You're mistaken -- nothing has been pushed to master in the last 3 hours. I am not mistaken. I have removed it from my local copy, but have not pushed it yet since I am adding links to the docs. It will be done today. -- 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 Fri, May 10, 2019 at 05:10:06PM +1200, David Rowley wrote: > On Fri, 10 May 2019 at 16:52, Justin Pryzby <pryzby@telsasoft.com> wrote: > > I'm rechecking my list from last month. What about these ? > > > > > c076f3d Remove pg_constraint.conincluding > > > bd09503 Increase the default vacuum_cost_limit from 200 to 2000 > > bd09503 was reverted in 52985e4fea7 and replaced by cbccac371, which > is documented already by: > > <para> Reduce the default value of <varname>autovacuum_vacuum_cost_delay</varname> to 2ms (Tom Lane) </para> Right, thanks. I suspect c076f3d should be included, though. Also, |The many system tables with such columns will now display those columns with SELECT * by default. I think could be better: |SELECT * will now output those columns for the many system tables which have them. |(previously, the columns weren't shown unless explicitly selected). Justin
On Mon, May 13, 2019 at 12:48:00PM -0500, Justin Pryzby wrote: > I suspect c076f3d should be included, though. bd47c4a9 has removed pg_constraint.conincluding from REL_11_STABLE as well. -- Michael
Attachment
On Mon, May 13, 2019 at 12:48:00PM -0500, Justin Pryzby wrote:
> On Fri, May 10, 2019 at 05:10:06PM +1200, David Rowley wrote:
> > On Fri, 10 May 2019 at 16:52, Justin Pryzby <pryzby@telsasoft.com> wrote:
> > > I'm rechecking my list from last month. What about these ?
> > >
> > > > c076f3d Remove pg_constraint.conincluding
> > > > bd09503 Increase the default vacuum_cost_limit from 200 to 2000
> >
> > bd09503 was reverted in 52985e4fea7 and replaced by cbccac371, which
> > is documented already by:
> >
> > <para> Reduce the default value of <varname>autovacuum_vacuum_cost_delay</varname> to 2ms (Tom Lane) </para>
>
> Right, thanks.
>
> I suspect c076f3d should be included, though.
This commit was part of a set of patches that forced a catalog version
changes in PG 11 in early September, 2018.
> |The many system tables with such columns will now display those columns with SELECT * by default.
> I think could be better:
> |SELECT * will now output those columns for the many system tables which have them.
> |(previously, the columns weren't shown unless explicitly selected).
Good idea. The new text is:
<command>SELECT *</command> will now output those columns for the many
system tables which have them. Previously, the columns had to be selected
explicitly.
--
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 +