Horton

Re: On disable_cost

Laurenz Albe <laurenz.albe@cybertec.at>

View thread View on postgr.es
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Alena Rybakina <a.rybakina@postgrespro.ru>
Cc: David Rowley <dgrowleyml@gmail.com>, 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-10-02T19:08:03Z
Lists: pgsql-hackers 
On Wed, 2024-10-02 at 21:31 +0300, Alena Rybakina wrote:
> Honestly, I like this patch. Before this patch, when disabling any algorithm
> in the optimizer, the cost increased significantly and I’m not sure that this
> was a reliable solution due to the fact that the cost even without disabling
> can be greatly increased because of the high cardinality, for example.
>
> Right there, the mechanism is simple and more honest in my opinion - we simply
> count the number of disabled nodes and discard the paths with the largest
> number of them.

I have no issue with this way of handling disabled plan nodes, I only
complained about the verbosity of the EXPLAIN output.

I don't want to see disabled nodes propagated all the way up the tree,
and I would like the output suppressed by default.

Yours,
Laurenz Albe

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.