Re: On disable_cost

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Zhenghua Lyu <zlyu(at)vmware(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: On disable_cost
Date: 2024-04-02 16:58:18
Message-ID: 1657775.1712077098@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Apr 2, 2024 at 11:54 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I suspect that it'd behave poorly when there are both disabled and
>> promoted sub-paths in a tree, for pretty much the same reasons you
>> explained just upthread.

> Hmm, can you explain further? I think essentially you'd be maximizing
> #(promoted notes)-#(disabled nodes), but I have no real idea whether
> that behavior will be exactly what people want or extremely
> unintuitive or something in the middle. It seems like it should be
> fine if there's only promoting or only disabling or if we can respect
> both the promoting and the disabling, assuming we even want to have
> both, but I'm suspicious that it will be weird somehow in other cases.
> I can't say exactly in what way, though. Do you have more insight?

Not really. But if you had, say, a join of a promoted path to a
disabled path, that would be treated as on-par with a join of two
regular paths, which seems like it'd lead to odd choices. Maybe
it'd be fine, but my gut says it'd likely not act nicely. As you
say, it's a lot easier to believe that only-promoted or only-disabled
situations would behave sanely.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2024-04-02 16:59:08 Re: Statistics Import and Export
Previous Message Tom Lane 2024-04-02 16:50:14 Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs