Re: On disable_cost

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Geoghegan <pg(at)bowt(dot)ie>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: On disable_cost
Date: 2024-07-02 19:28:38
Message-ID: CA+Tgmoa-nn+jypLTiG1BzOHLL1O-heSzyCrPPbw=Ah7McEex4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 2, 2024 at 2:37 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > What happens right now is:
>
> > - If you set enable_indexscan=false, then disable_cost is added to the
> > cost of index scan paths and the cost of index-only scan paths.
>
> > - If you set enable_indexonlyscan=false, then index-only scan paths
> > are not generated at all.
>
> Hm. The first part of that seems pretty weird to me --- why don't
> we simply not generate the paths at all? There is no case AFAIR
> where that would prevent us from generating a valid plan.

Well, yeah.

What the patch does is: if you set either enable_indexscan=false or
enable_indexonlyscan=false, then the corresponding path type is not
generated, and the other is unaffected. To me, that seems like the
logical way to clean this up.

One could argue for other things, of course. And maybe those other
things are fine, if they're properly justified and documented.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-07-02 19:36:56 Re: On disable_cost
Previous Message Joel Jacobson 2024-07-02 18:53:23 Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands.