Avoid CREATE INDEX unique index deduplication.
authorPeter Geoghegan <pg@bowt.ie>
Fri, 17 Jul 2020 16:50:48 +0000 (09:50 -0700)
committerPeter Geoghegan <pg@bowt.ie>
Fri, 17 Jul 2020 16:50:48 +0000 (09:50 -0700)
There is no advantage to attempting deduplication for a unique index
during CREATE INDEX, since there cannot possibly be any duplicates.
Doing so wastes cycles due to unnecessary copying.  Make sure that we
avoid it consistently.

We already avoided unique index deduplication in the case where there
were some spool2 tuples to merge.  That didn't account for the fact that
spool2 is removed early/unset in the common case where it has no tuples
that need to be merged (i.e. it failed to account for the "spool2 turns
out to be unnecessary" optimization in _bt_spools_heapscan()).

Oversight in commit 0d861bbb, which added nbtree deduplication

Backpatch: 13-, where nbtree deduplication was introduced.

src/backend/access/nbtree/nbtsort.c

index e6b72111363e2be69de53f0cff3d7c21b925d3d6..efee86784bbf59cc06e5a262d69dccaef19604e4 100644 (file)
@@ -1192,7 +1192,7 @@ _bt_load(BTWriteState *wstate, BTSpool *btspool, BTSpool *btspool2)
        int64           tuples_done = 0;
        bool            deduplicate;
 
-       deduplicate = wstate->inskey->allequalimage &&
+       deduplicate = wstate->inskey->allequalimage && !btspool->isunique &&
                BTGetDeduplicateItems(wstate->index);
 
        if (merge)