Re: index paths and enable_indexscan - Mailing list pgsql-hackers

From Amit Langote
Subject Re: index paths and enable_indexscan
Date
Msg-id CA+HiwqHhGqRW9uA9OoXMWF2nX-x3odZ8TirpM6=AWoODE8mjHw@mail.gmail.com
Whole thread Raw
In response to Re: index paths and enable_indexscan  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: index paths and enable_indexscan  (Andy Fan <zhihui.fan1213@gmail.com>)
List 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 by date:

Previous
From: davinder singh
Date:
Subject: Re: PG compilation error with Visual Studio 2015/2017/2019
Next
From: Pavel Stehule
Date:
Subject: Display of buffers for planning time show nothing for second run