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: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>, David Rowley <dgrowleyml(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: On disable_cost
Date: 2024-10-07 22:41:42
Message-ID: 1781867.1728340902@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 Sat, Oct 5, 2024 at 3:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW, getting off the question of EXPLAIN output for a moment,
>> I don't understand why disable_cost is still a thing. The
>> one remaining usage seems trivial to replace, as attached.

> I believe I commented on that somewhere upthread, but maybe I meant to
> and didn't or maybe you didn't see it in the flurry of emails.
> Basically, I wasn't confident that it made sense to treat this as the
> same kind of thing as other cases where we increment disabled_nodes.

I don't buy your argument that this case is so special that it
warrants preserving disable_cost. I certainly didn't think it
was special when I added it.

There may be another way to do this that doesn't rely on disabling
the path in the same way as the user-accessible knobs do, but
I don't really believe it's worth the trouble to think of one.
And I definitely don't want to keep disable_cost around even for
just one usage, because then we've not fixed the user-experience
aspect of this (that is, "why does this plan have a ridiculously high
cost?"), nor have we fixed all the concerns you had about higher-level
planning decisions being skewed by that cost.

One other point here is that if disable_cost remains exposed as a
global variable (as it is in HEAD), there is no reason to expect
that any extensions that are using it will get on board with the
new approach.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2024-10-07 22:45:25 Re: pg_parse_json() should not leak token copies on failure
Previous Message Masahiko Sawada 2024-10-07 22:23:08 Re: Make COPY format extendable: Extract COPY TO format implementations