Ignore BRIN indexes when checking for HOT updates

When determining whether an index update may be skipped by using HOT, we
can ignore attributes indexed by block summarizing indexes without
references to individual tuples that need to be cleaned up.

A new type TU_UpdateIndexes provides a signal to the executor to
determine which indexes to update - no indexes, all indexes, or only the
summarizing indexes.

This also removes rd_indexattr list, and replaces it with rd_attrsvalid
flag. The list was not used anywhere, and a simple flag is sufficient.

This was originally committed as 5753d4ee32, but then got reverted by
e3fcca0d0d because of correctness issues.

Original patch by Josef Simanek, various fixes and improvements by Tomas
Vondra and me.

Authors: Matthias van de Meent, Josef Simanek, Tomas Vondra
Reviewed-by: Tomas Vondra, Alvaro Herrera
Discussion: https://postgr.es/m/05ebcb44-f383-86e3-4f31-0a97a55634cf@enterprisedb.com
Discussion: https://postgr.es/m/CAFp7QwpMRGcDAQumN7onN9HjrJ3u4X3ZRXdGFT0K5G2JWvnbWg%40mail.gmail.com

1 files changed, 27 insertions, 10 deletions

diff --git a/src/backend/executor/execIndexing.c b/src/backend/executor/execIndexing.c
index 6e88e72813f..da28e5e40ca 100644
--- a/src/backend/executor/execIndexing.c
+++ b/src/backend/executor/execIndexing.c
@@ -259,15 +259,24 @@ ExecCloseIndices(ResultRelInfo *resultRelInfo)
  *		into all the relations indexing the result relation
  *		when a heap tuple is inserted into the result relation.
  *
- *		When 'update' is true, executor is performing an UPDATE
- *		that could not use an optimization like heapam's HOT (in
- *		more general terms a call to table_tuple_update() took
- *		place and set 'update_indexes' to true).  Receiving this
- *		hint makes us consider if we should pass down the
- *		'indexUnchanged' hint in turn.  That's something that we
- *		figure out for each index_insert() call iff 'update' is
- *		true.  (When 'update' is false we already know not to pass
- *		the hint to any index.)
+ *		When 'update' is true and 'onlySummarizing' is false,
+ *		executor is performing an UPDATE that could not use an
+ *		optimization like heapam's HOT (in more general terms a
+ *		call to table_tuple_update() took place and set
+ *		'update_indexes' to TUUI_All).  Receiving this hint makes
+ *		us consider if we should pass down the 'indexUnchanged'
+ *		hint in turn.  That's something that we figure out for
+ *		each index_insert() call iff 'update' is true.
+ *		(When 'update' is false we already know not to pass the
+ *		hint to any index.)
+ *
+ *		If onlySummarizing is set, an equivalent optimization to
+ *		HOT has been applied and any updated columns are indexed
+ *		only by summarizing indexes (or in more general terms a
+ *		call to table_tuple_update() took place and set
+ *		'update_indexes' to TUUI_Summarizing). We can (and must)
+ *		therefore only update the indexes that have
+ *		'amsummarizing' = true.
  *
  *		Unique and exclusion constraints are enforced at the same
  *		time.  This returns a list of index OIDs for any unique or
@@ -287,7 +296,8 @@ ExecInsertIndexTuples(ResultRelInfo *resultRelInfo,
 					  bool update,
 					  bool noDupErr,
 					  bool *specConflict,
-					  List *arbiterIndexes)
+					  List *arbiterIndexes,
+					  bool onlySummarizing)
 {
 	ItemPointer tupleid = &slot->tts_tid;
 	List	   *result = NIL;
@@ -343,6 +353,13 @@ ExecInsertIndexTuples(ResultRelInfo *resultRelInfo,
 		if (!indexInfo->ii_ReadyForInserts)
 			continue;
 
+		/*
+		 * Skip processing of non-summarizing indexes if we only
+		 * update summarizing indexes
+		 */
+		if (onlySummarizing && !indexInfo->ii_Summarizing)
+			continue;
+
 		/* Check for partial index */
 		if (indexInfo->ii_Predicate != NIL)
 		{