database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-29 22:49:41 +03:00
Code Activity

doc: Remove more notes about compatibilities with past versions

Browse Source 
This is a follow-up of the work done in fa42c2e, that did not include
all the fixes previously agreed on.  The contents removed here can be
confusing to the reader as they refer to rather old server versions.

Author: Stephen Frost, Tom Lane, Heikki Linnakangas, Yaroslav Schekin
Discussion: https://postgr.es/m/CAB8KJ=jYHgnxLLZSNJz7gBTck4TxomngCmGkw3nEMSNF0yL6wA@mail.gmail.com
Discussion: https://postgr.es/m/1599765595731-0.post@n3.nabble.com
This commit is contained in:
Michael Paquier
2020-12-01 16:32:26 +09:00
parent 57faaf376e
commit 8a17f44c1e
3 changed files with 11 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
doc/src/sgml/gin.sgml
View File

@@ -507,7 +507,7 @@
Updating a <acronym>GIN</acronym> index tends to be slow because of the
intrinsic nature of inverted indexes: inserting or updating one heap row
can cause many inserts into the index (one for each key extracted
from the indexed item). As of <productname>PostgreSQL</productname> 8.4,
from the indexed item).
<acronym>GIN</acronym> is capable of postponing much of this work by inserting
new tuples into a temporary, unsorted list of pending entries.
When the table is vacuumed or autoanalyzed, or when
@@ -576,10 +576,10 @@
</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.
When <literal>fastupdate</literal> is enabled for <acronym>GIN</acronym>
(see <xref linkend="gin-fast-update"/> for details), the penalty is
less than when it is not. But for very large updates it may still be
best to drop and recreate the index.
</para>
</listitem>
</varlistentry>