Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on
Date
Msg-id CAAKRu_ZPwmbsATDXFWigb3vW3iKmEnHjBNJ3G2z2vwXF72q5Bg@mail.gmail.com
Whole thread Raw
In response to Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Tue, Oct 22, 2024 at 3:21 PM David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Wed, 23 Oct 2024 at 02:08, Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> > However, it seems like there should be a way to force an index-only
> > scan even if it is not the cheapest path. Perhaps I only think this as
> > a developer needing to test something. But if enable_indexscan
> > disables index-only scan then I don't see how I can force an
> > index-only scan when it is not cheapest.
>
> The way to do that is to turn off enable_seqscan and enable_bitmapscan
> and ensure your query can support IOS.
>
> The important part to remember here is that when creating the index
> paths, the Index Only Scan is always assumed to be better than Index
> Scan whenever it's possible to use IOS. There's no opportunity that if
> an IOS is possible that you'll get an Index Scan instead.  See
> check_index_only() and build_index_paths() around where
> check_index_only() is used.

Ah, okay, I see. Thank you :)

- Melanie



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on
Next
From: Tom Lane
Date:
Subject: Re: Using Expanded Objects other than Arrays from plpgsql