Fix ginEntryInsert's counting of GIN leaf tuples.

As the code stands, nEntries counts the number of ginEntryInsert()
calls, so that's what you end up with at the end of a GIN index build.
However, ginvacuumcleanup() recomputes nEntries as the number of
surviving leaf tuples, and that's generally consistent with the way that
gincostestimate() uses the value.  So let's clearly define nEntries
as the number of leaf tuples, and therefore adjust ginEntryInsert() to
increment it only when we make a new one, not when we add TIDs into an
existing tuple or posting tree.

In practice this inconsistency probably has little impact, so I don't
feel a need to back-patch.

Insung Moon and Keisuke Kuroda

Discussion: https://postgr.es/m/CAEMmqBuH_O-oXL+3_ArQ6F5cJ7kXVow2SGQB3HRacku_T+xkmA@mail.gmail.com

1 files changed, 7 insertions, 4 deletions

diff --git a/src/backend/access/gin/gininsert.c b/src/backend/access/gin/gininsert.c
index 55eab14617..6eb83639aa 100644
--- a/src/backend/access/gin/gininsert.c
+++ b/src/backend/access/gin/gininsert.c
@@ -190,10 +190,6 @@ ginEntryInsert(GinState *ginstate,
 
 	insertdata.isDelete = false;
 
-	/* During index build, count the to-be-inserted entry */
-	if (buildStats)
-		buildStats->nEntries++;
-
 	ginPrepareEntryScan(&btree, attnum, key, category, ginstate);
 	btree.isBuild = (buildStats != NULL);
 
@@ -234,6 +230,13 @@ ginEntryInsert(GinState *ginstate,
 		/* no match, so construct a new leaf entry */
 		itup = buildFreshLeafTuple(ginstate, attnum, key, category,
 								   items, nitem, buildStats, stack->buffer);
+
+		/*
+		 * nEntries counts leaf tuples, so increment it only when we make a
+		 * new one.
+		 */
+		if (buildStats)
+			buildStats->nEntries++;
 	}
 
 	/* Insert the new or modified leaf tuple */