Re: Why order by column not using index with distinct keyword in select clause?
В списке pgsql-general по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Why order by column not using index with distinct keyword in select clause? |
| Дата | |
| Msg-id | 21078.1536674828@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Why order by column not using index with distinct keyword in selectclause? (Arup Rakshit <ar@zeit.io>) |
| Список | pgsql-general |
Arup Rakshit <ar@zeit.io> writes:
> I have define a simple B Tree index on column *country* for users table. I don’t understand why the order by column
notusing the index scan when using *distinct* keyword in the select clause. Can anyone explain what is happening here?
Doesn't look complicated to me: the cost of the hashagg+sort plan is
283.85, while the cost of the indexscan plans is 886.27, and adding
a Uniq node on top of them would have been even more.
The critical point here seems to be that the hashagg node is able to
get rid of so many rows that the cost of sorting what remains is low.
Also notable is that the IOS isn't giving you any advantage over a
plain indexscan, which apparently is because none of the table's
pages are marked all-visible. If the table is static then a VACUUM
would help that.
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера