| От | Tom Lane |
|---|---|
| Тема | Re: merge>hash>loop |
| Дата | |
| Msg-id | 20064.1145403513@sss.pgh.pa.us обсуждение |
| Ответ на | Re: merge>hash>loop (Markus Schaber <schabi@logix-tt.com>) |
| Список | pgsql-performance |
Markus Schaber <schabi@logix-tt.com> writes:
> An easy first approach would be to add a user tunable cache probability
> value to each index (and possibly table) between 0 and 1. Then simply
> multiply random_page_cost with (1-that value) for each scan.
That's not the way you'd need to use it. But on reflection I do think
there's some merit in a "cache probability" parameter, ranging from zero
(giving current planner behavior) to one (causing the planner to assume
everything is already in cache from prior queries). We'd have to look
at exactly how such an assumption should affect the cost equations ...
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера