Re: On disable_cost

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'm willing to agree with you. I think we should display it not all the time.

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

I may have misunderstood your message, but disabled nodes number must propagate up the tree, otherwise it will be incorrect.

Let consider an example. We disabled seqscan, so the hashjoin containing it cannot be equal to 0, since such a path in principle should not be generated because a path must be generated that does not contain seqscan. It should use indexscan, for example. Therefore the hash join path containing indexscan will have fewer disabled nodes and will finally be used by the optimizer.

-- 
Regards,
Alena Rybakina
Postgres Professional