Re: pgsql: docs: fist draft version of the PG 12 release notes
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
pgsql: postgres_fdw: Fix typo in comment.
postgres_fdw: Fix typo in comment. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/af16f0a7045da816d33d8b23045eca5c2473342c Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: postgres_fdw: Fix typo in comment.
postgres_fdw: Fix typo in comment. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7c16a2bfdcd8d477c8ff39c5eeb7d3b87fe0d60b Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: postgres_fdw: Fix typo in comment.
postgres_fdw: Fix typo in comment. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cc866941ad4583f07e5637c145f6f6ee8a573e11 Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: postgres_fdw: Fix typo in comment.
postgres_fdw: Fix typo in comment. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6ba0ff47cd9a7e86298dca3ead112eb27ae21265 Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix misuse of an integer as a bool.
Fix misuse of an integer as a bool. pgtls_read_pending is declared to return bool, but what the underlying SSL_pending function returns is a count of available bytes. This is actually somewhat harmless if we're using C99 bools, but in the back branches it's a live bug: if the available-bytes count happened to be a multiple of 256, it would get converted to a zero char value. On machines where char is signed, counts of 128 and up could misbehave as well. The net effect is that when using SSL, libpq might block waiting for data even though some has already been received. Broken by careless refactoring in commit 4e86f1b16, so back-patch to 9.5 where that came in. Per bug #15802 from David Binderman. Discussion: https://postgr.es/m/15802-f0911a97f0346...@postgresql.org Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e3bf3c0f8c9c880ba808bc11c2825ecba720e4ed Modified Files -- src/interfaces/libpq/fe-misc.c | 2 +- src/interfaces/libpq/fe-secure-openssl.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix misuse of an integer as a bool.
Fix misuse of an integer as a bool. pgtls_read_pending is declared to return bool, but what the underlying SSL_pending function returns is a count of available bytes. This is actually somewhat harmless if we're using C99 bools, but in the back branches it's a live bug: if the available-bytes count happened to be a multiple of 256, it would get converted to a zero char value. On machines where char is signed, counts of 128 and up could misbehave as well. The net effect is that when using SSL, libpq might block waiting for data even though some has already been received. Broken by careless refactoring in commit 4e86f1b16, so back-patch to 9.5 where that came in. Per bug #15802 from David Binderman. Discussion: https://postgr.es/m/15802-f0911a97f0346...@postgresql.org Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0ec3d2ab250ef696f5e32d4ff7779849bfb0770d Modified Files -- src/interfaces/libpq/fe-misc.c | 2 +- src/interfaces/libpq/fe-secure-openssl.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix misuse of an integer as a bool.
Fix misuse of an integer as a bool. pgtls_read_pending is declared to return bool, but what the underlying SSL_pending function returns is a count of available bytes. This is actually somewhat harmless if we're using C99 bools, but in the back branches it's a live bug: if the available-bytes count happened to be a multiple of 256, it would get converted to a zero char value. On machines where char is signed, counts of 128 and up could misbehave as well. The net effect is that when using SSL, libpq might block waiting for data even though some has already been received. Broken by careless refactoring in commit 4e86f1b16, so back-patch to 9.5 where that came in. Per bug #15802 from David Binderman. Discussion: https://postgr.es/m/15802-f0911a97f0346...@postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ddf927fb13471bec0cc76794eaf552df8a1178fb Modified Files -- src/interfaces/libpq/fe-misc.c | 2 +- src/interfaces/libpq/fe-secure-openssl.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix misuse of an integer as a bool.
Fix misuse of an integer as a bool. pgtls_read_pending is declared to return bool, but what the underlying SSL_pending function returns is a count of available bytes. This is actually somewhat harmless if we're using C99 bools, but in the back branches it's a live bug: if the available-bytes count happened to be a multiple of 256, it would get converted to a zero char value. On machines where char is signed, counts of 128 and up could misbehave as well. The net effect is that when using SSL, libpq might block waiting for data even though some has already been received. Broken by careless refactoring in commit 4e86f1b16, so back-patch to 9.5 where that came in. Per bug #15802 from David Binderman. Discussion: https://postgr.es/m/15802-f0911a97f0346...@postgresql.org Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6b0e9411ff0f0116d6f9118a870a682a17eea110 Modified Files -- src/interfaces/libpq/fe-misc.c | 2 +- src/interfaces/libpq/fe-secure-openssl.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix misuse of an integer as a bool.
Fix misuse of an integer as a bool. pgtls_read_pending is declared to return bool, but what the underlying SSL_pending function returns is a count of available bytes. This is actually somewhat harmless if we're using C99 bools, but in the back branches it's a live bug: if the available-bytes count happened to be a multiple of 256, it would get converted to a zero char value. On machines where char is signed, counts of 128 and up could misbehave as well. The net effect is that when using SSL, libpq might block waiting for data even though some has already been received. Broken by careless refactoring in commit 4e86f1b16, so back-patch to 9.5 where that came in. Per bug #15802 from David Binderman. Discussion: https://postgr.es/m/15802-f0911a97f0346...@postgresql.org Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8eaba0b93da10659f8796d6e740f656476d4925f Modified Files -- src/interfaces/libpq/fe-misc.c | 2 +- src/interfaces/libpq/fe-secure-openssl.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Improve comment for att_isnull.
Improve comment for att_isnull. The comment implies that a 1 in the null bitmap indicates a null value, but actually a 0 in the null bitmap indicates a null value. Try to be more clear. Patch by me; proposed wording reviewed by Alvaro Herrera and Tom Lane. Discussion: http://postgr.es/m/CA+TgmobHOP8r6cG+UnsDFMrS30-m=jrrcbhgw-nfkn0k9qn...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/221b377f09a30dd7c74c26c8c1db439afcc59141 Modified Files -- src/include/access/tupmacs.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
pgsql: Don't leave behind junk nbtree pages during split.
Don't leave behind junk nbtree pages during split. Commit 8fa30f906be reduced the elevel of a number of "can't happen" _bt_split() errors from PANIC to ERROR. At the same time, the new right page buffer for the split could continue to be acquired well before the critical section. This was possible because it was relatively straightforward to make sure that _bt_split() could not throw an error, with a few specific exceptions. The exceptional cases were safe because they involved specific, well understood errors, making it possible to consistently zero the right page before actually raising an error using elog(). There was no danger of leaving around a junk page, provided _bt_split() stuck to this coding rule. Commit 8224de4f, which introduced INCLUDE indexes, added code to make _bt_split() truncate away non-key attributes. This happened at a point that broke the rule around zeroing the right page in _bt_split(). If truncation failed (perhaps due to palloc() failure), that would result in an errant right page buffer with junk contents. This could confuse VACUUM when it attempted to delete the page, and should be avoided on general principle. To fix, reorganize _bt_split() so that truncation occurs before the new right page buffer is even acquired. A junk page/buffer will not be left behind if _bt_nonkey_truncate()/_bt_truncate() raise an error. Discussion: https://postgr.es/m/CAH2-WzkcWT_-NH7EeL=Az4efg0KCV+wArygW8zKB=+HoP=v...@mail.gmail.com Backpatch: 11-, where INCLUDE indexes were introduced. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9b42e713761a43e9ade3965285f077e2ba25bbb7 Modified Files -- src/backend/access/nbtree/nbtinsert.c | 213 -- 1 file changed, 126 insertions(+), 87 deletions(-)
pgsql: Don't leave behind junk nbtree pages during split.
Don't leave behind junk nbtree pages during split. Commit 8fa30f906be reduced the elevel of a number of "can't happen" _bt_split() errors from PANIC to ERROR. At the same time, the new right page buffer for the split could continue to be acquired well before the critical section. This was possible because it was relatively straightforward to make sure that _bt_split() could not throw an error, with a few specific exceptions. The exceptional cases were safe because they involved specific, well understood errors, making it possible to consistently zero the right page before actually raising an error using elog(). There was no danger of leaving around a junk page, provided _bt_split() stuck to this coding rule. Commit 8224de4f, which introduced INCLUDE indexes, added code to make _bt_split() truncate away non-key attributes. This happened at a point that broke the rule around zeroing the right page in _bt_split(). If truncation failed (perhaps due to palloc() failure), that would result in an errant right page buffer with junk contents. This could confuse VACUUM when it attempted to delete the page, and should be avoided on general principle. To fix, reorganize _bt_split() so that truncation occurs before the new right page buffer is even acquired. A junk page/buffer will not be left behind if _bt_nonkey_truncate()/_bt_truncate() raise an error. Discussion: https://postgr.es/m/CAH2-WzkcWT_-NH7EeL=Az4efg0KCV+wArygW8zKB=+HoP=v...@mail.gmail.com Backpatch: 11-, where INCLUDE indexes were introduced. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bf78f50bae0b3b5ffcbf3e3c5b03fd138be15f9a Modified Files -- src/backend/access/nbtree/nbtinsert.c | 207 -- 1 file changed, 123 insertions(+), 84 deletions(-)
pgsql: Fix logical replication's ideas about which type OIDs are built-
Fix logical replication's ideas about which type OIDs are built-in. Only hand-assigned type OIDs should be presumed to match across different PG servers; those assigned during genbki.pl or during initdb are likely to change due to addition or removal of unrelated objects. This means that the cutoff should be FirstGenbkiObjectId (in HEAD) or FirstBootstrapObjectId (before that), not FirstNormalObjectId. Compare postgres_fdw's is_builtin() test. It's likely that this error has no observable consequence in a normally-functioning system, since ATM the only affected type OIDs are system catalog rowtypes and information_schema types, which would not typically be interesting for logical replication. But you could probably break it if you tried hard, so back-patch. Discussion: https://postgr.es/m/15150.1557257...@sss.pgh.pa.us Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b6abc2241ac4549623d6894d7855765df6345ad5 Modified Files -- src/backend/replication/logical/relation.c | 2 +- src/backend/replication/pgoutput/pgoutput.c | 10 +++--- 2 files changed, 8 insertions(+), 4 deletions(-)
pgsql: Fix logical replication's ideas about which type OIDs are built-
Fix logical replication's ideas about which type OIDs are built-in. Only hand-assigned type OIDs should be presumed to match across different PG servers; those assigned during genbki.pl or during initdb are likely to change due to addition or removal of unrelated objects. This means that the cutoff should be FirstGenbkiObjectId (in HEAD) or FirstBootstrapObjectId (before that), not FirstNormalObjectId. Compare postgres_fdw's is_builtin() test. It's likely that this error has no observable consequence in a normally-functioning system, since ATM the only affected type OIDs are system catalog rowtypes and information_schema types, which would not typically be interesting for logical replication. But you could probably break it if you tried hard, so back-patch. Discussion: https://postgr.es/m/15150.1557257...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/32ebb35128c3d16b64039f6d6774afd96a3d91b9 Modified Files -- src/backend/replication/logical/relation.c | 2 +- src/backend/replication/pgoutput/pgoutput.c | 10 +++--- 2 files changed, 8 insertions(+), 4 deletions(-)
pgsql: Improve commentary about hack in is_publishable_class().
Improve commentary about hack in is_publishable_class(). The FirstNormalObjectId test here is a kluge that needs to go away, but the only substitute we can think of is to add a column to pg_class, which will take more work than can be handled right now. Add some commentary in the meanwhile. Discussion: https://postgr.es/m/15150.1557257...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e34ee993fbc38c8538f9342c5961e5f61fd45180 Modified Files -- src/backend/catalog/pg_publication.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-)
pgsql: Fix logical replication's ideas about which type OIDs are built-
Fix logical replication's ideas about which type OIDs are built-in. Only hand-assigned type OIDs should be presumed to match across different PG servers; those assigned during genbki.pl or during initdb are likely to change due to addition or removal of unrelated objects. This means that the cutoff should be FirstGenbkiObjectId (in HEAD) or FirstBootstrapObjectId (before that), not FirstNormalObjectId. Compare postgres_fdw's is_builtin() test. It's likely that this error has no observable consequence in a normally-functioning system, since ATM the only affected type OIDs are system catalog rowtypes and information_schema types, which would not typically be interesting for logical replication. But you could probably break it if you tried hard, so back-patch. Discussion: https://postgr.es/m/15150.1557257...@sss.pgh.pa.us Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3b505036a129af5bbbf40a00f8997fc15438bb38 Modified Files -- src/backend/replication/logical/relation.c | 2 +- src/backend/replication/pgoutput/pgoutput.c | 10 +++--- 2 files changed, 8 insertions(+), 4 deletions(-)
pgsql: Doc: Refer to line pointers as item identifiers.
Doc: Refer to line pointers as item identifiers. An upcoming HEAD-only patch will standardize the terminology around ItemIdData variables/line pointers, ending the practice of referring to them as "item pointers". Make the "Database Page Layout" docs consistent with the new policy. The term "item identifier" is already used in the same section, so stick with that. Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=e4ndq2--...@mail.gmail.com Backpatch: All supported branches. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6bbc2f9b66104de67f29881c54e75fd6f5d2f694 Modified Files -- doc/src/sgml/storage.sgml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Doc: Refer to line pointers as item identifiers.
Doc: Refer to line pointers as item identifiers. An upcoming HEAD-only patch will standardize the terminology around ItemIdData variables/line pointers, ending the practice of referring to them as "item pointers". Make the "Database Page Layout" docs consistent with the new policy. The term "item identifier" is already used in the same section, so stick with that. Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=e4ndq2--...@mail.gmail.com Backpatch: All supported branches. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/80873a6ec590cdbe10ca0cd987b8ca3dcf5ef764 Modified Files -- doc/src/sgml/storage.sgml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Doc: Refer to line pointers as item identifiers.
Doc: Refer to line pointers as item identifiers. An upcoming HEAD-only patch will standardize the terminology around ItemIdData variables/line pointers, ending the practice of referring to them as "item pointers". Make the "Database Page Layout" docs consistent with the new policy. The term "item identifier" is already used in the same section, so stick with that. Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=e4ndq2--...@mail.gmail.com Backpatch: All supported branches. Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dd01bbf00cbfd58fae6195070c2440f8f2187045 Modified Files -- doc/src/sgml/storage.sgml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Doc: Refer to line pointers as item identifiers.
Doc: Refer to line pointers as item identifiers. An upcoming HEAD-only patch will standardize the terminology around ItemIdData variables/line pointers, ending the practice of referring to them as "item pointers". Make the "Database Page Layout" docs consistent with the new policy. The term "item identifier" is already used in the same section, so stick with that. Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=e4ndq2--...@mail.gmail.com Backpatch: All supported branches. Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bc96e394c23b66728349cbe429a3239a35fe29af Modified Files -- doc/src/sgml/storage.sgml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Doc: Refer to line pointers as item identifiers.
Doc: Refer to line pointers as item identifiers. An upcoming HEAD-only patch will standardize the terminology around ItemIdData variables/line pointers, ending the practice of referring to them as "item pointers". Make the "Database Page Layout" docs consistent with the new policy. The term "item identifier" is already used in the same section, so stick with that. Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=e4ndq2--...@mail.gmail.com Backpatch: All supported branches. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0569f047e8d65f1ed08280bc9ad535cfbbe0829a Modified Files -- doc/src/sgml/storage.sgml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Doc: Refer to line pointers as item identifiers.
Doc: Refer to line pointers as item identifiers. An upcoming HEAD-only patch will standardize the terminology around ItemIdData variables/line pointers, ending the practice of referring to them as "item pointers". Make the "Database Page Layout" docs consistent with the new policy. The term "item identifier" is already used in the same section, so stick with that. Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=e4ndq2--...@mail.gmail.com Backpatch: All supported branches. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/08ca9d7feca890e97f77ef1fde02d7542a54ac5e Modified Files -- doc/src/sgml/storage.sgml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Standardize ItemIdData terminology.
Standardize ItemIdData terminology. The term "item pointer" should not be used to refer to ItemIdData variables, since that is needlessly ambiguous. Only ItemPointerData/ItemPointer variables should be called item pointers. To fix, establish the convention that ItemIdData variables should always be referred to either as "item identifiers" or "line pointers". The term "item identifier" already predominates in docs and translatable messages, and so should be the preferred alternative there. Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=e4ndq2--...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ae7291acbc5ae4c3751615177fc256f9f3399403 Modified Files -- contrib/amcheck/verify_nbtree.c | 4 ++-- src/backend/access/heap/README.HOT | 10 +- src/backend/access/heap/heapam.c | 4 ++-- src/backend/access/heap/heapam_handler.c | 2 +- src/backend/access/heap/pruneheap.c | 10 +- src/backend/access/heap/vacuumlazy.c | 6 +++--- src/backend/access/index/indexam.c | 26 -- src/backend/access/nbtree/nbtinsert.c| 2 +- src/backend/access/spgist/spgvacuum.c| 2 +- src/backend/storage/page/bufpage.c | 26 +- src/include/access/htup_details.h| 2 +- src/include/access/itup.h| 2 +- src/include/storage/bufpage.h| 16 ++-- src/include/storage/itemid.h | 13 +++-- 14 files changed, 52 insertions(+), 73 deletions(-)
pgsql: Fix duplicated words in comments
Fix duplicated words in comments Author: Stephen Amell Discussion: https://postgr.es/m/539fa271-21b3-777e-a468-d96cffe9c...@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7e19929ea29668f3d01280262e407b93042c959a Modified Files -- src/backend/executor/execExpr.c | 2 +- src/backend/replication/logical/reorderbuffer.c | 2 +- src/include/c.h | 2 +- src/include/jit/llvmjit_emit.h | 4 ++-- src/include/nodes/execnodes.h | 2 +- src/include/replication/logical.h | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-)
pgsql: doc: properly attibute PG 12 pgbench release note item
doc: properly attibute PG 12 pgbench release note item Reported-by: Fabien COELHO Discussion: https://postgr.es/m/alpine.DEB.2.21.1905130839140.13487@lancre Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5d971565a7993ba8dcd06d34d1387af48fdbd034 Modified Files -- doc/src/sgml/release-12.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: improve wording of PG 12 releaase note partition item
doc: improve wording of PG 12 releaase note partition item Reported-by: Amit Langote Discussion: https://postgr.es/m/d5267ae5-bd4a-3e96-c21b-56bfa9fec...@lab.ntt.co.jp Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f4125278e3c92d8cdd83c77d0b54f468ee81c750 Modified Files -- doc/src/sgml/release-12.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: pgsql: docs: fist draft version of the PG 12 release notes
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 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 +
pgsql: doc: Update OID item in PG 12 release notes
doc: Update OID item in PG 12 release notes Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20190513174759.ge23...@telsasoft.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0b62f0f2552d895301fdae56aa839c1eaae24a3a Modified Files -- doc/src/sgml/release-12.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
