From ec28808ba85853fa14b090199236ca555273607e Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 4 Nov 2019 14:16:42 -0500 Subject: [PATCH] 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 --- src/backend/access/gin/gininsert.c | 11 +++++++---- 1 file 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 */