Re: index paths and enable_indexscan

On Tue, Apr 14, 2020 at 4:58 PM Amit Langote <amitlangote09(at)gmail(dot)com>
wrote:

> On Tue, Apr 14, 2020 at 5:29 PM Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:
> > On Tue, Apr 14, 2020 at 3:40 PM Amit Langote <amitlangote09(at)gmail(dot)com>
> wrote:
> >> On Tue, Apr 14, 2020 at 4:13 PM Richard Guo <guofenglinux(at)gmail(dot)com>
> wrote:
> >> > On Tue, Apr 14, 2020 at 2:44 PM Amit Langote <amitlangote09(at)gmail(dot)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.
> >
> > I guess that is because user may disable seqscan as well. If so, we
> > still need formula to decide with one to use, which requires index path
> > has to be calculated. but since disabling the two at the same time is
> rare,
> > we can ignore the index path build if user allow seqscan
>
> I am saying that instead of building index path with disabled cost,
> just don't build it at all. A base rel will always have a sequetial
> path, even though with disabled cost if enable_seqscan = off.
>

Let's say user set enable_seqscan=off and set enable_indexscan=off;
will you expect user to get seqscan at last? If so, why is seqscan
(rather than index scan) since both are disabled by user equally?

> Amit Langote
> EnterpriseDB: http://www.enterprisedb.com
>