Re: index paths and enable_indexscan

On Tue, Apr 14, 2020 at 4:58 PM Amit Langote <amitlangote09@gmail.com> wrote:

On Tue, Apr 14, 2020 at 5:29 PM Andy Fan <zhihui.fan1213@gmail.com> wrote:
> On Tue, Apr 14, 2020 at 3:40 PM Amit Langote <amitlangote09@gmail.com> wrote:
>> 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.
>
> 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