Re: index paths and enable_indexscan
От | Amit Langote |
---|---|
Тема | Re: index paths and enable_indexscan |
Дата | |
Msg-id | CA+HiwqHhGqRW9uA9OoXMWF2nX-x3odZ8TirpM6=AWoODE8mjHw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: index paths and enable_indexscan (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: index paths and enable_indexscan
|
Список | pgsql-hackers |
On Tue, Apr 14, 2020 at 4:13 PM Richard Guo <guofenglinux@gmail.com> wrote: > On Tue, Apr 14, 2020 at 2:44 PM Amit Langote <amitlangote09@gmail.com> wrote: >> Maybe I am missing something obvious, but is it intentional that >> enable_indexscan is checked by cost_index(), that is, *after* creating >> an index path? I was expecting that if enable_indexscan is off, then >> no index paths would be generated to begin with, because I thought >> they are optional. > > > I think the cost estimate of index paths is the same as other paths on > that setting enable_xxx to off only adds a penalty factor (disable_cost) > to the path's cost. The path would be still generated and compete with > other paths in add_path(). Yeah, but I am asking why build the path to begin with, as there will always be seq scan path for base rels. Turning enable_hashjoin off, for example, means that no hash join paths will be built at all. Looking into the archives, I see that the idea of "not generating disabled paths to begin with" was discussed quite recently: https://www.postgresql.org/message-id/29821.1572706653%40sss.pgh.pa.us -- Amit Langote EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: