| От | Tom Lane |
|---|---|
| Тема | Re: Why is there a Sort after an Index Only Scan? |
| Дата | |
| Msg-id | 2604686.1651716539@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | RE: Why is there a Sort after an Index Only Scan? (André Hänsel <andre@webkr.de>) |
| Список | pgsql-performance |
=?UTF-8?Q?Andr=C3=A9_H=C3=A4nsel?= <andre@webkr.de> writes:
> Limit (cost=0.43..296.63 rows=50 width=4) (actual time=1052.692..1052.737 rows=50 loops=1)
> -> Index Scan using orders_test_pkey on orders_test (cost=0.43..71149.43 rows=12010 width=4) (actual
time=1052.690..1052.728rows=50 loops=1)
> Filter: ((shipping_date >= '2022-04-30'::date) AND (shipping_date <= '2022-05-01'::date))
> Rows Removed by Filter: 1998734
> Is it overestimating the cost of the sorting?
No, but it's guessing it will hit 50 rows that satisfy the filter
before it's gone very far in this index. If the shipping date and
pkey are correlated in the wrong direction, that could be a very
overoptimistic guess. I don't think we have adequate stats yet
to detect this sort of problem.
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера