Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on
Date: 2024-10-29 01:25:13
Message-ID: CAKFQuwZ_=kMDuPePWjGx1V6mB5WYPzxDQSR7E=usg0mOQ2a3fg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 28, 2024 at 6:03 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> We don't seem to be agreeing on much here... :-(
>
> On Tue, 29 Oct 2024 at 13:30, David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >
> > On Mon, Oct 28, 2024 at 3:54 PM David Rowley <dgrowleyml(at)gmail(dot)com>
> wrote:
> >> I'm concerned about the wording "all index-scan related". It's not
> >> that clear if that would include Bitmap Index Scans or not.
> >
> >
> > That was partially the point of writing "all" there - absent other
> information, and seeing how index-only scans were treated, I presumed it
> was indeed actually or effectively a switch for all. If it is not it
> should be made clear which node types with the word index in them are not
> affected.
>
> I'm very much against mentioning which things are *not* affected by
> settings. It doesn't seem like a very sustainable way to write
> documentation.
>

The documentation presently uses the term "index-scan related" and it is
unclear what exactly that is supposed to cover. My addition of the word
"all" doesn't materially change this other than for certain covering the
"index-only-scan related" nodes that gets clarified and is
cross-referenced. If you are uncertain whether adding "all" is meant to
cover Bitmap Index Scans then your uncertainty still exists in the current
wording. I just added "all" to be explicit about that fact, or at least
that is what I thought I did.

For me, the answer to "are bitmap index scans disabled" by setting
enable_indexscans to off is "yes" and does not require explanation. If the
real answer is "no" then please propose a change that can disabuse me of my
belief.

> > Is there a listing of all node types produced by PostgreSQL (with the
> explain output naming) along with which ones are affected by which enable_*
> knobs (possibly multiple for something like Bitmap Index Scan)?
>
> No. We purposefully do our best not to document executor nodes. The
> enable_* GUCs is one place where it's hard to avoid.
>

For education, mainly mine, not to add to the documentation; though our
lack of detail here for what are user-facing things is IMO unfortunate.

> >>
> >> Could we just add "The <xref linkend="guc-enable-indexscan"/> setting
> >> must also be enabled to have the query planner consider
> >> index-only-scans"?
> >
> >
> > I'd like to stick with a conjunction there but agree the "must be
> enabled" wording is preferrable, avoiding the double-negative.
> >
> > "The default is on, but the <xref> setting must also be enabled."
> >
> > The 'to have the...' part seems to just be redundant.
>
> I think it's confusing to include this as part of the mention of what
> the default value is. The default value and enable_indexscans being
> the master switch aren't at all related.
>
>
Fair point. I'm good with your proposed change here.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2024-10-29 01:26:23 Re: detoast datum into the given buffer as a optimization.
Previous Message Michael Paquier 2024-10-29 01:24:59 Re: ActiveState Perl is not valid anymore to build PG17 on the Windows 10/11 platforms, So Documentation still suggesting it should be updated