Re: On disable_cost

On 03.10.2024 23:10, Laurenz Albe wrote:
> On Thu, 2024-10-03 at 14:24 -0400, Robert Haas wrote:
>> On Thu, Oct 3, 2024 at 1:35 PM Alena Rybakina<a(dot)rybakina(at)postgrespro(dot)ru> wrote:
>>> I prepared a patch that includes the information we can add.
>> One general thing to think about is that we really document very
>> little about EXPLAIN. That might not be good, but we should consider
>> whether it will look strange if we document a bunch of stuff about
>> this and still don't talk about anything else.
>>
>> (This is not a comment on this specific patch, which I have not
>> examined. It's just a general thought.)
I think we should still add it because it might cause a lot of
misunderstanding.
> The "EXPLAIN Basics" already mention "enable_seqscan", so I think it is
> alright to expand on that a bit.
>
> Here is my take on a documentation patch (assuming David's "Disabled: true"
> wording):
>
> diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
> index ff689b65245..db906841472 100644
> --- a/doc/src/sgml/perform.sgml
> +++ b/doc/src/sgml/perform.sgml
> @@ -578,6 +578,28 @@ WHERE t1.unique1 &lt; 100 AND t1.unique2 = t2.unique2;
> discussed <link linkend="using-explain-analyze">below</link>.
> </para>
>
> + <para>
> + Some plan node types cannot be completely disabled. For example, there is
> + no other access method than a sequential scan for a table with no index.
> + If you told the planner to disregard a certain node type, but it is forced
> + to use it nonetheless, you will see the plan node marked as
> + <quote>Disabled</quote> in the output of <command>EXPLAIN</command>:
> +
> +<screen>
> +CREATE TABLE dummy (t text);
> +
> +SET enable_seqscan = off;
> +
> +EXPLAIN SELECT * FROM dummy;
> +
> + QUERY PLAN
> +----------------------------------------------------------
> + Seq Scan on dummy (cost=0.00..23.60 rows=1360 width=32)
> + Disabled: true
> +</screen>
> +
> + </para>
> +
> <para>
> <indexterm>
> <primary>subplan</primary>
>
>
Sorry for the late reply, I needed time to look into this feature to
respond to your email.
I think this is not entirely correct. I tested last version of the patch
[0]: I created a table and disabled sequential scanning, so there were
no other options for optimizer to scan table t1. it still displayed that
it has disabled nodes.
However you are right that this display will not appear for all nodes
that only contain a data collection procedure, such as Append,
MergeAppend, Gather, etc. And I agree with you that we should
information about it. I also think it’s worth adding additional
information that this option does not appear in the postgres_fdw extension.

--
Regards,
Alena Rybakina
Postgres Professional