Avoid CREATE INDEX unique index deduplication.

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.

diff --git a/src/backend/access/nbtree/nbtsort.c b/src/backend/access/nbtree/nbtsort.c
index c03998834d4a1915864824c9c1f9ebe314e55f72..c5c7fc8a2dac4483cb6ee653aa43533bee54c23e 100644 (file)
--- a/src/backend/access/nbtree/nbtsort.c
+++ b/src/backend/access/nbtree/nbtsort.c
@@ -1191,7 +1191,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)