agora inbox for [email protected]
help / color / mirror / Atom feedFrom: Justin Pryzby <[email protected]>
Subject: [PATCH 2/3] from stephen
Date: Mon, 26 Oct 2020 16:26:07 -0500
---
doc/src/sgml/func.sgml | 14 +++++---------
doc/src/sgml/gin.sgml | 19 ++++++++-----------
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 5c27cc2b13..1ea88a8c67 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -2309,15 +2309,11 @@ repeat('Pg', 4) <returnvalue>PgPgPgPg</returnvalue>
<note>
<para>
- Before <productname>PostgreSQL</productname> 8.3, these functions would
- silently accept values of several non-string data types as well, due to
- the presence of implicit coercions from those data types to
- <type>text</type>. Those coercions have been removed because they frequently
- caused surprising behaviors. However, the string concatenation operator
- (<literal>||</literal>) still accepts non-string input, so long as at least one
- input is of a string type, as shown in <xref
- linkend="functions-string-sql"/>. For other cases, insert an explicit
- coercion to <type>text</type> if you need to duplicate the previous behavior.
+ The string concatenation operator (<literal>||</literal>) will accept
+ non-string input, so long as at least one input is of string type, as shown
+ in <xref linkend="functions-string-sql"/>. For other cases, inserting an
+ explicit coercion to <type>text</type> can be used to have non-string input
+ accepted.
</para>
</note>
diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml
index 67754f52f6..cfbb1e0761 100644
--- a/doc/src/sgml/gin.sgml
+++ b/doc/src/sgml/gin.sgml
@@ -569,17 +569,14 @@
<term>Create vs. insert</term>
<listitem>
<para>
- Insertion into a <acronym>GIN</acronym> index can be slow
- due to the likelihood of many keys being inserted for each item.
- So, for bulk insertions into a table it is advisable to drop the GIN
- index and recreate it after finishing bulk insertion.
- </para>
-
- <para>
- As of <productname>PostgreSQL</productname> 8.4, this advice is less
- necessary since delayed indexing is used (see <xref
- linkend="gin-fast-update"/> for details). But for very large updates
- it may still be best to drop and recreate the index.
+ Building a <acronym>GIN</acronym> index after all of the data has been
+ loaded will typically be faster than creating the index and then filling
+ it. There may also be cases where, for a sufficiently large update,
+ dropping the <acronym>GIN</acronym> index, then performing the update,
+ and then recreating the index will be faster than a routine update,
+ however, one should review the delayed indexing technique used for
+ <acronym>GIN</acronym> (see <xref linkend="gin-fast-update"/> for
+ details) and the options it provides.
</para>
</listitem>
</varlistentry>
--
2.17.0
--1ppIqr1kl39GnwQx
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0003-Remove-references-to-old-server-behavior.patch"
view thread (2+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected]
Subject: Re: [PATCH 2/3] from stephen
In-Reply-To: <no-message-id-185642@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox