Re: On disable_cost

From: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: On disable_cost
Date: 2024-10-08 15:12:36
Message-ID: bc01b846-a686-4d48-9d59-c245c7e4871b@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 07.10.2024 19:02, Laurenz Albe wrote:
> On Mon, 2024-10-07 at 10:17 +0300, Alena Rybakina wrote:
>>> 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>
>> 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.
> Isn't that exactly what my doc patch shows?
Sorry, you are right and this is correct. I think I misunderstood at
first because I was tired
>> 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.
> I cannot quite follow that either...
>
>
I meant this [0].

Th disabled description won't display if the MergeAppend and Append
nodes are used in the query plan. I tried to generalize it, but without
success. I'm not sure that these nodes can be called accumulating data.
But I tried to describe this case in the documentation.

About postgres_fdw extension disabled nodes won't show [1]. I think we
should add information about it too.

[0]
https://www.postgresql.org/message-id/CAApHDvpMyKJpLGWRmR3%2B3g4DxrSf6iRpwTRCXMorU0HvgWbocw%40mail.gmail.com

[1]
https://www.postgresql.org/message-id/CA%2BTgmoZRwy8202vxbUPBeZd_Tx5NYVtmpvBnJnOzZS3b81cpkg%40mail.gmail.com

--
Regards,
Alena Rybakina
Postgres Professional

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2024-10-08 15:19:46 Re: [PoC] Federated Authn/z with OAUTHBEARER
Previous Message Nathan Bossart 2024-10-08 15:11:08 Re: Statistics Import and Export