Re: On disable_cost

On 02.10.2024 22:08, Laurenz Albe wrote:
> 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