From d91dcd6613b06e6c0b4c7f720bdf3f37f0394841 Mon Sep 17 00:00:00 2001
From: James Coleman <jtc331@gmail.com>
Date: Fri, 31 Jul 2020 12:42:42 -0400
Subject: [PATCH v3 2/2] Document vacuum on one table depending on concurrent
 index creation

Because commands like VACUUM on one table are not considered when
determining what xids are safe to vacuum on another table, it's
operationally surprising that CREATE INDEX CONCURRENTLY on one table
is considered when determining what xids are safe to vacuum on another
table.
---
 doc/src/sgml/ref/create_index.sgml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index a37342ee77..0c7b9f6139 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -808,6 +808,12 @@ Indexes:
    performed in parallel.
   </para>
 
+  <para>
+   <command>CREATE INDEX</command> (including the <literal>CONCURRENTLY</literal>
+   option) commands are included when <command>VACUUM</command> calculates what
+   dead tuples are safe to remove even on tables other than the one being indexed.
+  </para>
+
   <para>
    Use <xref linkend="sql-dropindex"/>
    to remove an index.
-- 
2.20.1