Re: On disable_cost

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>
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-07 16:02:35
Message-ID: 0c9be59da045e2f1f74e1558118ac56d045d43cb.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

> 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...

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2024-10-07 16:05:53 Re: bt Scankey in another contradictory case
Previous Message Tom Lane 2024-10-07 16:02:10 Re: POC, WIP: OR-clause support for indexes