Обсуждение: 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: > > http://momjian.us/pgsql_docs/release-12.html > 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 > ------ > 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(-) > -- 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: > > > > http://momjian.us/pgsql_docs/release-12.html > > > > 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 > 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. 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 down > > Good point, done: > > http://momjian.us/pgsql_docs/release-12.html 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
On 2019/05/10 5:57, Bruce Momjian wrote: > 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? So the current text, which is: +<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> mentions improving "pruning" efficiency which applies only to SELECT/UPDATE/DELETE queries and can be attributed to only one of the many commits listed with this item. Performance of short INSERTs (as opposed to bulk-inserts including COPY) is also improved, but it has nothing to do "pruning". That said, efficiency is improved in both cases by not doing redundant work for partitions that are not affected by the query, that is, * for partitions which are pruned for a given SELECT/UPDATE/DELETE query (planner improvement) * for partitions which are not inserted into by a given INSERT statement (executor improvement, part of which was done in v11 but v11 still locks *all* partitions whereas v12 will only lock those that are inserted into) So, it might be fair to lump them, but maybe not use the word "pruning", because it describes only subset of affected workloads. Does that help? Thanks, Amit
+<listitem> +<!-- +Author: Alexander Korotkov <akorotkov@postgresql.org> +2018-07-28 [d2086b08b] Reduce path length for locking leaf B-tree pages during +Author: Peter Geoghegan <pg@bowt.ie> +2019-03-25 [f21668f32] Add "split after new tuple" nbtree optimization. +Author: Peter Geoghegan <pg@bowt.ie> +2019-04-23 [9b1092626] Prevent O(N^2) unique index insertion edge case. +--> + +<para> +Improve speed of btree index insertions (Alexander Korotkov, Peter Geoghegan) +</para> If we group these very heterogeneous together, then Peter's name probably should go first. Because he authored two quite complex optimization, while my one is rather simple. +<para> + LOOKUP, INDEX CLEANUP IMPROVEMENTS? +</para> +</listitem> Hmm... What is this paragraph supposed to mean? Did you have an idea to group more commit into this item? ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
On Thu, May 9, 2019 at 8:21 PM Alexander Korotkov <a.korotkov@postgrespro.ru> wrote: > If we group these very heterogeneous together, then Peter's name > probably should go first. Because he authored two quite complex > optimization, while my one is rather simple. I posted a patch over on the "pg12 release notes" thread. It suggested some changes to the draft release notes, including making your optimization into its own item that you alone are credited with. -- Peter Geoghegan
On Fri, May 10, 2019 at 6:28 AM Peter Geoghegan <pg@bowt.ie> wrote: > On Thu, May 9, 2019 at 8:21 PM Alexander Korotkov > <a.korotkov@postgrespro.ru> wrote: > > If we group these very heterogeneous together, then Peter's name > > probably should go first. Because he authored two quite complex > > optimization, while my one is rather simple. > > I posted a patch over on the "pg12 release notes" thread. It suggested > some changes to the draft release notes, including making your > optimization into its own item that you alone are credited with. Oh, I've missed that. Your patch looks good to me. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
On Fri, May 10, 2019 at 06:21:27AM +0300, Alexander Korotkov wrote: > +<listitem> > +<!-- > +Author: Alexander Korotkov <akorotkov@postgresql.org> > +2018-07-28 [d2086b08b] Reduce path length for locking leaf B-tree pages during > +Author: Peter Geoghegan <pg@bowt.ie> > +2019-03-25 [f21668f32] Add "split after new tuple" nbtree optimization. > +Author: Peter Geoghegan <pg@bowt.ie> > +2019-04-23 [9b1092626] Prevent O(N^2) unique index insertion edge case. > +--> > + > +<para> > +Improve speed of btree index insertions (Alexander Korotkov, Peter Geoghegan) > +</para> > > If we group these very heterogeneous together, then Peter's name > probably should go first. Because he authored two quite complex > optimization, while my one is rather simple. Done. > +<para> > + LOOKUP, INDEX CLEANUP IMPROVEMENTS? > +</para> > +</listitem> > > Hmm... What is this paragraph supposed to mean? Did you have an idea > to group more commit into this item? Please see the other thread where I used Peter's detail text. -- 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 10:54:32AM +0900, Amit Langote wrote:
> On 2019/05/10 5:57, Bruce Momjian wrote:
> > 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?
>
> So the current text, which is:
>
> +<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>
>
> mentions improving "pruning" efficiency which applies only to
> SELECT/UPDATE/DELETE queries and can be attributed to only one of the many
> commits listed with this item. Performance of short INSERTs (as opposed
> to bulk-inserts including COPY) is also improved, but it has nothing to do
> "pruning".
>
> That said, efficiency is improved in both cases by not doing redundant
> work for partitions that are not affected by the query, that is,
>
> * for partitions which are pruned for a given SELECT/UPDATE/DELETE query
> (planner improvement)
>
> * for partitions which are not inserted into by a given INSERT statement
> (executor improvement, part of which was done in v11 but v11 still locks
> *all* partitions whereas v12 will only lock those that are inserted into)
>
>
> So, it might be fair to lump them, but maybe not use the word "pruning",
> because it describes only subset of affected workloads.
I struggled to talk about partitioning since there were so many
improvements. I favored a more generic item that just suggested
dramatic improvements. I have modified the text to:
Improve performance of many operations on partitioned tables (Amit
Langote, David Rowley, Tom Lane, Álvaro Herrera)
Also, thousands of partitions can now be pruned efficiently.
Committed. Does that work?
--
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 2019/05/11 10:25, Bruce Momjian wrote: > I struggled to talk about partitioning since there were so many > improvements. I favored a more generic item that just suggested > dramatic improvements. I have modified the text to: > > Improve performance of many operations on partitioned tables (Amit > Langote, David Rowley, Tom Lane, Álvaro Herrera) > > Also, thousands of partitions can now be pruned efficiently. > > Committed. Thanks. > Does that work? That's better, but the second line still just mentions pruning efficiency. It's true that pruning large number of partitions got a lot quicker in this release, but that is by no means the only improvement. How about writing: Thousands of partitions can now be pruned efficiently. Also, inserting into partitioned tables no longer slows down as the number of partitions increases. or some such. Also, as David said on -advocacy [1] regarding pruning, it's not really that the core "pruning" algorithm itself was improved in this release. Speed-up came from reworking planner's (and to some extent executor's) use of the pruning functionality to be more efficient. But maybe it's fine to use the word "pruning" in the release notes to indicate that this speedup is only meaningful workloads that benefit from it. Thanks, Amit [1] https://www.postgresql.org/message-id/CAKJS1f-1%3DBoVkJaTnfb87nrVUFLprdc7smsBsF5MGyCXnNivzw%40mail.gmail.com
On Mon, May 13, 2019 at 04:01:36PM +0900, Amit Langote wrote:
> On 2019/05/11 10:25, Bruce Momjian wrote:
> > I struggled to talk about partitioning since there were so many
> > improvements. I favored a more generic item that just suggested
> > dramatic improvements. I have modified the text to:
> >
> > Improve performance of many operations on partitioned tables (Amit
> > Langote, David Rowley, Tom Lane, Álvaro Herrera)
> >
> > Also, thousands of partitions can now be pruned efficiently.
> >
> > Committed.
>
> Thanks.
>
> > Does that work?
>
> That's better, but the second line still just mentions pruning efficiency.
> It's true that pruning large number of partitions got a lot quicker in
> this release, but that is by no means the only improvement. How about
> writing:
>
> Thousands of partitions can now be pruned efficiently. Also, inserting
> into partitioned tables no longer slows down as the number of partitions
> increases.
>
> or some such.
I went with this wording:
Tables with thousands of child partitions can now be processed
efficiently.
--
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 +