| От | Tom Lane |
|---|---|
| Тема | Re: Index not being used in sorting of simple table |
| Дата | |
| Msg-id | 18314.1178498156@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Index not being used in sorting of simple table (Robins <tharakan@gmail.com>) |
| Список | pgsql-performance |
Robins <tharakan@gmail.com> writes:
> There is one thing though, that I couldn't really understand. Considering
> that A's correlation in pg_stats being very high compared to B, isn't it 'a
> better candidate' for a sequential scan as compared to B in this scenario ?
No, high correlation reduces the cost of an indexscan but doesn't do
anything much for a seqscan-and-sort. (Actually, I suppose it could
help by reducing the number of initial runs to be merged, but that's
not an effect the planner knows about.) The interesting point is that
Paul shows
SELECT tablename, attname, correlation FROM pg_stats where tablename='x';
x | a | 0.977819
x | b | 0.78292
when his initial verbal description indicated that b should have the
better correlation. So that's something else odd about this case.
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера