| От | Tom Lane |
|---|---|
| Тема | Re: Delete query takes exorbitant amount of time |
| Дата | |
| Msg-id | 21461.1112107257@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Delete query takes exorbitant amount of time (Simon Riggs <simon@2ndquadrant.com>) |
| Ответы |
Re: Delete query takes exorbitant amount of time
|
| Список | pgsql-performance |
Simon Riggs <simon@2ndquadrant.com> writes:
> ...but, I see no way for OidFunctionCall8 to ever return an answer of
> "always just 1 row, no matter how big the relation"...so tuples_fetched
> is always proportional to the size of the relation. Are unique indexes
> treated just as very-low-selectivity indexes?
Yeah. It is not the job of amcostestimate to estimate the number of
rows, only the index access cost. (IIRC there is someplace in the
planner that explicitly considers unique indexes as a part of developing
selectivity estimates ... but it's not that part.)
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера