Horton

Re: On disable_cost

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>, David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-02T19:54:17Z
Lists: pgsql-hackers 
On Tue, Jul 2, 2024 at 3:36 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > One could argue for other things, of course. And maybe those other
> > things are fine, if they're properly justified and documented.
>
> [ shrug... ]  This isn't a hill that I'm prepared to die on.
> But I see no good reason to change the very long-standing
> behaviors of these GUCs.

Well, I don't really know where to go from here. I mean, I think that
three committers (David, Heikki, yourself) have expressed some
concerns about changing the behavior. So maybe we shouldn't. But I
don't understand how it's reasonable to have two very similarly named
GUCs behave (1) inconsistently with each other and (2) in a way that
cannot be guessed from the documentation.

I feel like we're just clinging to legacy behavior on the theory that
somebody, somewhere might be relying on it in some way, which they
certainly might be. But that doesn't seem like a great reason, either.

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

Commits

  1. Doc: add detail about EXPLAIN's "Disabled" property

  2. Adjust EXPLAIN's output for disabled nodes

  3. Fix order of parameters in a cost_sort call

  4. Show number of disabled nodes in EXPLAIN ANALYZE output.

  5. Treat number of disabled nodes in a path as a separate cost metric.

  6. Remove grotty use of disable_cost for TID scan plans.