Thread: Pg uses non-unique index instead of pkey index

EXPLAIN'ing the very simple query:
SELECT * FROM experimentsc WHERE expid=12;

I get the following plan:
NOTICE:  QUERY PLAN:

Index Scan using experimentsc_expid_i on experimentsc  (cost=0.00..2.01 rows=1 width=44)

EXPLAIN

I have two indeces on the same thing: expid  (don't as why :^) One is the index formed because it is the primary key,
andthe other I created manually. 

test=# \di expe
            List of relations
          Name          | Type  | Owner
------------------------+-------+--------
 experimentsc_expid_i   | index | thalis
 experimentsc_expname_i | index | thalis
 experimentsc_pkey      | index | pgsql
(3 rows)

test=# \d experimentsc_expid_i
Index "experimentsc_expid_i"
 Attribute |  Type
-----------+---------
 expid     | integer
btree

test=# \d experimentsc_pkey
Index "experimentsc_pkey"
 Attribute |  Type
-----------+---------
 expid     | integer
unique btree (primary key)


Why exactly is experimentsc_expid_i chosen over experimentsc_pkey? Not that it would make any difference in this case,
butI'd guess that an equality condition on the pkey should go for the corresponding index. 

TIA,
thalis


ps hopefully not because it comes first in lexicographic ordering ;-)

"Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> writes:
> Why exactly is experimentsc_expid_i chosen over experimentsc_pkey?

There is no reason to prefer either one over the other.  So you get
a quasi-random choice (whichever one the optimizer happens to consider
first, I think).

            regards, tom lane