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-22T13:08:37Z
Lists: pgsql-hackers
On Mon, Oct 21, 2024 at 9:32 PM David Rowley <dgrowleyml@gmail.com> wrote: > > There's nothing new about Index Only Scans being disabled by > enable_indexscan. Index Only Scan is chosen with your test case as all > possible Paths are disabled and IOS is the cheapest of all Paths. Ah, I see! Sorry, I didn't think to compare and see what the cheapest path would be if all paths were disabled and, of course, planner still needs to pick one. Thanks! > Robert did propose to change this behaviour while he was working on > the disabled_nodes changes. I did push back on the proposed change > [1]. If you feel strongly that what we have is wrong, then maybe it's > worth opening the discussion about that again. I suppose if you think of index-only scan as a kind of subclass of index scan, then disabling index scan should disable index-only scan. 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. - 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