Re: EXPLAIN IndexOnlyScan shows disabled when enable_indexonlyscan=on

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: 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-22 13:08:37
Message-ID: CAAKRu_bx6xdx6AY9cWuEUzWbyuvJ+JY=OfvTPTLpxxg_aoaqUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 21, 2024 at 9:32 PM David Rowley <dgrowleyml(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2024-10-22 13:12:43 Re: Row pattern recognition
Previous Message Daniil Davydov 2024-10-22 11:34:19 Re: Do not lock temp relations