I am curious as to whether
CREATE INDEX idx ON tbl (columns);
vs.
CREATE UNIQUE INDEX idx ON tbl (columns);
has a significant algorithmic performance benefit in PostgreSQL or MySQL implementations when scanning the indexed column(s), or whether the UNIQUE keyword simply introduces a unique constraint alongside the index.
I imagine it is probably fair to say that there is a marginal benefit insofar as indexes are likely to be internally implemented as some sort of hash1-like structure, and collision handling by definition result in something other than O(1) performance. Given this premise, it is likely that if a large percentage of values are identical than the structure degenerates into something linear.
So, for purposes of my question, assume that the distribution of values is relatively discrete and uniform.
Thanks in advance!
1 Which is a matter of pure speculation for me, as I am not familiar with RDBM internals.
If your data are unique, you should create a
UNIQUEindex on them.This implies no additional overhead and affects optimizer’s decisions in certain cases so that it can choose a better algorithm.
In
SQL Serverand inPostgreSQL, for instance, if you sort on aUNIQUEkey, the optimizer ignores theORDER BYclauses used after that (since they are irrelevant), i. e. this query:will use an index on
col_uniqueand won’t sort onother_colbecause it’s useless.This query:
will also be converted into an
INNER JOIN(as opposed to aSEMI JOIN) if there is aUNIQUEindex onothertable.othercol.An index always contains some kind of a pointer to the row (
ctidinPostgreSQL, row pointer inMyISAM, primary key/uniquifier inInnoDB) and the leaves are ordered on these pointers, so in fact every index leaf is unique is some way (though it may not be obvious).See this article in my blog for performance details:
UNIQUE