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

diff --git a/src/backend/access/gin/gininsert.c b/src/backend/access/gin/gininsert.c
index 55eab1461733af71111f1841ef372087b6868050..6eb83639aa0465695b5d8f86f26e3d31fee0057f 100644 (file)
--- 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 */