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: Jian Guo <gjian(at)vmware(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Zhenghua Lyu <zlyu(at)vmware(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: On disable_cost
Date: 2024-03-12 19:36:38
Message-ID: 1717369.1710272198@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, Mar 12, 2024 at 1:32 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW, having written that paragraph, I wonder if we couldn't get
>> the same end result with a nearly one-line change that consists of
>> making disable_cost be IEEE infinity.

> I don't think so, because I think that what will happen in that case
> is that we'll pick a completely random plan if we can't pick a plan
> that avoids incurring disable_cost. Every plan that contains one
> disabled node anywhere in the plan tree will look like it has exactly
> the same cost as any other such plan.

Good point.

> IMHO, this is actually one of the problems with disable_cost as it
> works today.

Yeah. I keep thinking that the right solution is to not generate
disabled paths in the first place if there are any other ways to
produce the same relation. That has obvious order-of-operations
problems though, and I've not been able to make it work.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-03-12 19:54:47 Re: On disable_cost
Previous Message Cary Huang 2024-03-12 18:57:44 typo in paths.h