Re: get_actual_variable_range vs idx_scan/idx_tup_fetch, again
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: get_actual_variable_range vs idx_scan/idx_tup_fetch, again |
| Дата | |
| Msg-id | 12326.1520262537@sss.pgh.pa.us обсуждение |
| Ответ на | get_actual_variable_range vs idx_scan/idx_tup_fetch, again (Marko Tiikkaja <marko@joh.to>) |
| Ответы |
Re: get_actual_variable_range vs idx_scan/idx_tup_fetch, again
|
| Список | pgsql-hackers |
Marko Tiikkaja <marko@joh.to> writes:
> So I'm in the same pickle again. According to pg_stat_user_indexes an
> index is being used all the time. However, it's only being used by
> mergejoinscansel() to compare these two plans:
If it's not being used otherwise, could you drop it?
> I think it would be really important to have a way to turn off
> get_actual_variable_range() for a specific index during runtime. Would a C
> level hook be acceptable for this?
You haven't really made a case for why you (or anyone else) should care.
As long as the planner makes the right choice, having investigated a wrong
choice doesn't seem like a bug to me.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера