Re: Surprised by index choice for count(*)
| От | David G. Johnston |
|---|---|
| Тема | Re: Surprised by index choice for count(*) |
| Дата | |
| Msg-id | CAKFQuwZR4mibLsfe2YtECMz3jpKACukVTs3abdBTiVx4yxrSog@mail.gmail.com обсуждение исходный текст |
| Ответ на | Surprised by index choice for count(*) (Rob Sargent <robjsargent@gmail.com>) |
| Список | pgsql-general |
Should I be? I would have thought the pk would have been chosen v. function index?
Indexes:
"segment_pkey" PRIMARY KEY, btree (id)
"useg" UNIQUE, btree (probandset_id, chrom, startbase, endbase)
"fpv" btree (pv(events_less, events_equal, events_greater, 0))
"segment_markerset_id_probandset_id_idx" btree (markerset_id, probandset_id)
Haven't looked at the code but among those 4 indexes the one that was chosen is the one that comes first alphabetically. Ideally it would avoid multi-column indexes since they are larger; and I believe that a float is smaller than a uuid so not only alphabetically but the fpv index wins on size too.
That the index is functional is immaterial here.
David J.
В списке pgsql-general по дате отправления: