Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on - Mailing list pgsql-hackers
From | David Rowley |
---|---|
Subject | Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on |
Date | |
Msg-id | CAApHDvqUSiu5k_qofptpvzftFjXQtojWGDMyGO3o0w+9kDhJOA@mail.gmail.com Whole thread Raw |
In response to | Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on ("David G. Johnston" <david.g.johnston@gmail.com>) |
Responses |
Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on
|
List | pgsql-hackers |
We don't seem to be agreeing on much here... :-( On Tue, 29 Oct 2024 at 13:30, David G. Johnston <david.g.johnston@gmail.com> wrote: > > On Mon, Oct 28, 2024 at 3:54 PM David Rowley <dgrowleyml@gmail.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 nodetypes 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. >> I think >> it's better to explicitly mention index-only-scans to make it clear >> which nodes are affected. > > I hadn't considered Bitmap Index Scans but I would expect if you do not use index scans then the ability to produce bitmapsfrom them would be precluded. > > I could see pointing out, in enable_bitmapscan, that enable_bitmapscan is effectively disabled (for index inputs) whenenable_indexscan is set to off. Then, in enable_indexscan, add a "see also" to enable_bitmapscan with a brief reasonas well. I don't follow this. enable_bitmapscan is completely independent from enable_indexscan. > Is there a listing of all node types produced by PostgreSQL (with the explain output naming) along with which ones areaffected 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. >> >> + types. The default is <literal>on</literal>. The >> index-only-scan plan types >> + can be independently disabled by setting <xref >> linkend="guc-enable-indexonlyscan"/> >> + to <literal>off</literal>. >> >> I wondered if it's better to reference the enable_indexonlyscan GUC >> here rather than document what enable_indexonlyscan does from the >> enable_indexscan docs. Maybe just a "Also see enable_indexonlyscans." >> could be added? > > > I prefer to briefly explain why we advise the reader to go "see also" here. > >> >> - The default is <literal>on</literal>. >> + The default is <literal>on</literal>. However, this setting >> has no effect if >> + <xref linkend="guc-enable-indexscan"/> is set to >> <literal>off</literal>. >> >> 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. David
pgsql-hackers by date: