From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: index paths and enable_indexscan |
Date: | 2020-04-14 07:39:46 |
Message-ID: | CA+HiwqHhGqRW9uA9OoXMWF2nX-x3odZ8TirpM6=AWoODE8mjHw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-04-14 08:17:35 | Display of buffers for planning time show nothing for second run |
Previous Message | davinder singh | 2020-04-14 07:37:40 | Re: PG compilation error with Visual Studio 2015/2017/2019 |