We have a table:
sjr_local1db=# \d cons_refs
Table "public.cons_refs"
Column | Type | Modifiers
-----------+------------------------+----------------------------------
code | bigint | not null
...
ref_type | character varying(20) | not null
ref_text | character varying(128) | not null
Indexes:
"cons_refs_pk" PRIMARY KEY, btree (code, ref_type)
"cons_refs_ref_type_ref_text_in" btree (ref_type, lower(ref_text::text))
I do a select :
ricodb=> explain analyze select * from cons_refs where ref_type = 'some_ref'
AND cons_code = 12345678;
QUERY PLAN
-----------------------------------------------------------------------------
Index Scan using cons_refs_pk on cons_refs (cost=0.00..37.89 rows=67
width=68) (actual time=0.020..0.021 rows=1 loops=1)
Index Cond: ((code = 12345678) AND ((ref_type)::text = 'some_ref'::text))
Total runtime: 0.036 ms
(3 rows)
Why does the plan come up with 67 rows, when by definition there can be at
most one as we are searching on the pk?
[pg 9.0.7 on RHEL 5.7]
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
