Horton

Re: On disable_cost

David Rowley <dgrowleyml@gmail.com>

View thread View on postgr.es
From: David Rowley <dgrowleyml@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-09-27T12:04:20Z
Lists: pgsql-hackers

Attachments

On Fri, 27 Sept 2024 at 20:42, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> 2. The "disabled nodes" are not only shown at the nodes where nodes
>    were actually disabled, but also at every nodes above these nodes.

I'm also not a fan either and I'd like to see this output improved.

It seems like it's easy enough to implement some logic to detect when
a given node is disabled just by checking if the disable_nodes count
is higher than the sum of the disabled_node field of the node's
children.  If there are no children (a scan node) and disabed_nodes >
0 then it must be disabled. There's even a nice fast path where we
don't need to check the children if disabled_nodes == 0.

Here's a POC grade patch of how I'd rather see it looking.

I opted to have a boolean field as I didn't see any need for an
integer count. I also changed things around so we always display the
boolean property in non-text EXPLAIN. Normally, we don't mind being
more verbose there.

I also fixed a bug in make_sort() where disabled_nodes isn't being set
properly. I'll do an independent patch for that if this goes nowhere.

David

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.