Re: On disable_cost - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: On disable_cost
Date
Msg-id ccbe8ab940da76d388af7fc3fd169f1dedf751f6.camel@cybertec.at
Whole thread Raw
In response to On disable_cost  (Zhenghua Lyu <zlv@pivotal.io>)
List pgsql-hackers
On Fri, 2024-10-11 at 20:45 +1300, David Rowley wrote:
> diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
> index ff689b6524..861b9cf0bc 100644
> --- a/doc/src/sgml/perform.sgml
> +++ b/doc/src/sgml/perform.sgml
> @@ -578,6 +578,34 @@ WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
>      discussed <link linkend="using-explain-analyze">below</link>.
>     </para>
>
> +   <para>
> +    When using the enable/disable flags to disable plan node types, the
> +    majority of the flags only deprioritize the corresponding plan node

I don't like "deprioritize".
How about "discourage the use of"?

Besides, is that really the majority?  I had though that only a few nodes
are unavoidable (sequential scan, sort, nested loop).  But I guess I am wrong.

> +    and don't outright disallow the planner's ability to use the plan node
> +    type.  This is done so that the planner still maintains the ability to
> +    form a plan for a given query.  Otherwise, certain queries would not be
> +    possible to execute when certain plan node types are disabled.  This means

"would not be possible to execute" can be simplified to "could be executed".

> +    it is possible that the planner chooses a plan using a node that has been
> +    disabled.  When this happens, the <command>EXPLAIN</command> output will
> +    indicate this fact.
> +
> +<screen>
> +SET enable_seqscan = off;
> +EXPLAIN SELECT * FROM unit;
> +
> +                       QUERY PLAN
> +---------------------------------------------------------
> + Seq Scan on unit  (cost=0.00..21.30 rows=1130 width=44)
> +   Disabled: true
> +</screen>
> +   </para>
> +
> +   <para>
> +    Because the <literal>unit</literal> table has no indexes, there is no
> +    other means to read the table data, so the <literal>Seq Scan</literal>
> +    is the only option available to the query planner.
> +   </para>
> +

Can we have "sequential scan" instead of "Seq Scan"?
It's somewhat unrelated, but I cannot count how many people I have talked
to who think that it is a "sequence scan".

Yours,
Laurenz Albe



pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: Doc of typmod arg perhaps deserves an update
Next
From: Bertrand Drouvot
Date:
Subject: Re: Add contrib/pg_logicalsnapinspect