Re: index paths and enable_indexscan

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

> Turning enable_hashjoin off,
> for example, means that no hash join paths will be built at all.
>
>
As for join, the difference is even user allows a join method by setting,
but the planner may still not able to use it. so the disabled path still
need
to be used. Consider query "select * from t1, t2 where f(t1.a, t2.a) = 3",
and user setting is enable_nestloop = off, enable_hashjoin = on.
But I think it is still possible to ignore the path generating after
some extra checking.

> 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
>
>
>