Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on
Melanie Plageman <melanieplageman@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>,
Robert Haas <robertmhaas@gmail.com>
Date: 2024-10-22T19:28:34Z
Lists: 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
Commits
-
Doc: clarify enable_indexscan=off also disabled Index Only Scans
- 857f13f79994 12.21 landed
- ee8db41a9432 13.17 landed
- ca643bcd7a81 14.14 landed
- 75f09cc460a3 15.9 landed
- 4f47ee03d5f8 16.5 landed
- e5086b3ff441 17.1 landed
- dda781609f97 18.0 landed