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 <tgl@xxxxxxxxxxxxx> wrote: > > Kevin Wooten <kdubb@xxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
