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-04-01 21:00:11
Message-ID: 1318489.1712005211@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:
> One of the things I realized relatively early is that the patch does
> nothing to propagate disable_cost upward through the plan tree.
> ...
> After straining my brain over various plan changes for a long time,
> and hacking on the code somewhat, I realized that just propagating the
> Boolean upward is insufficient to set things right. That's basically
> because I was being dumb when I said this:
>> I don't think we should care how MANY disabled nodes appear in a
>> plan, particularly.

Very interesting, thanks for the summary. So the fact that
disable_cost is additive across plan nodes is actually a pretty
important property of the current setup. I think this is closely
related to one argument you made against my upthread idea of using
IEEE Infinity for disable_cost: that'd mask whether more than one
of the sub-plans had been disabled.

> ... And while there's probably more than one way
> to make it work, the easiest thing seems to be to just have a
> disabled-counter in every node that gets initialized to the total
> disabled-counter values of all of its children, and then you add 1 if
> that node is itself doing something that is disabled, i.e. the exact
> opposite of what I said in the quote above.

Yeah, that seems like the next thing to try if anyone plans to pursue
this further. That'd essentially do what we're doing now except that
disable_cost is its own "order of infinity", entirely separate from
normal costs.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-04-01 21:03:28 Re: Security lessons from liblzma
Previous Message Bruce Momjian 2024-04-01 20:59:51 Re: Security lessons from liblzma