Re: On disable_cost

Alena Rybakina <a.rybakina@postgrespro.ru>

From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, 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-10-06T23:09:00Z
Lists: pgsql-hackers
On 06.10.2024 02:22, David Rowley wrote:
>> To be honest, I don’t understand at all why we don’t count disabled nodes for append here? As I understand it, this is due to the fact that the partitioned table can also be scanned by an index. Besides mergeappend, in general it’s difficult for me to generalize for which nodes this rule applies, can you explain here?
> There are no special rules here of what to display based on the node
> type. Maybe you think there are some special rules because of the
> special cases for Append and MergeAppend in the patch? Those are
> handled specially as they don't use the Plan's lefttree and righttree
> fields.

To be honest, I didn't quite understand initially why we don't display 
information about disabled nodes for Append and MergeAppend, therefore I 
had a question about other cases.  Thank you for your explanation it was 
helpful!

I also checked the code to see what parameters there are for these nodes 
(Append and MergeAppend) and how they are processed.
To sum up, they provide for collecting information from child nodes. I 
agree that they do not need additional display about disabled nodes.

> Are you saying that the "Disabled: true" should propagate to the root
> of the plan tree?  That fact that master does that is what Laurenz and
> I are complaining about. I'm not sure if I follow what you're asking.

I agree that it's better to display such information for a specific 
disabled node. It's clearer what's going on and what it means.

-- 
Regards,
Alena Rybakina
Postgres Professional

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.