git.postgresql.org Git - postgresql.git/commitdiff

git projects / postgresql.git / commitdiff

Fix ginEntryInsert's counting of GIN leaf tuples.

Mon, 4 Nov 2019 19:16:42 +0000 (14:16 -0500)

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 patch | blob | blame | history

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);