This affirmation that it indeed does work set me straight. I inadvertently made a previously immutable UUID function volatile; it was providing the UUIDs in the query.
> On Nov 9, 2014, at 2:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Kevin Wooten <kd...@me.com> writes: >> I am assuming I am crazy and missing something completely obvious but I >> cannot get postgres (9.3.5) to use an index on a UUID, ever. > > Worksforme: > > regression=# create table foo (f1 uuid primary key); > CREATE TABLE > regression=# explain select * from foo where f1 = > 'a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11'; > QUERY PLAN > -------------------------------------------------------------------------- > Index Only Scan using foo_pkey on foo (cost=0.15..8.17 rows=1 width=16) > Index Cond: (f1 = 'a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11'::uuid) > (2 rows) > >> The main table has a natural composite key (2 uuids and a timestamp) with >> which it always uses the timestamp as the index condition and filters on the >> UUIDs. > > This probably has little to do with the datatype as such, and much to do > with the specifics of your query, the available indexes, and the table's > statistics. It's hard to speculate further without lots more detail > about those things. > > regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
