From 0b500eb54ab4735fc52c15f128a8723e1ca13d4f Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Mon, 26 Oct 2020 16:26:07 -0500
Subject: [PATCH 2/3] from stephen

---
 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