MIME-Version: 1.0
References: <8f25c08c-acb2-47ca-b8c1-6664fc31a361@thefreecat.org>
 <CAApHDvoUdvw68oHnfACQE=u8XPJ+Te49dZsfC2yW+DVfzdT2+Q@mail.gmail.com>
 <32dc1fe9-175a-4894-b4c4-c6cdc6a76a16@gmail.com>
 <CAApHDvodjGfmN8_na70Bn5OVPO1-gQo64s6n=HUxqnUUQFsUZA@mail.gmail.com>
 <ed9e8643-a7ed-48b7-abea-6eb74e71e043@gmail.com>
In-Reply-To: <ed9e8643-a7ed-48b7-abea-6eb74e71e043@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Fri, 19 Sep 2025 13:05:11 +1200
Message-ID: 
 <CAApHDvogm2ULHZUnmrzX+V3QQmB7cVE6+8-B91P+LcemTQSC9Q@mail.gmail.com>
Subject: Re: Why isn't PG using an index-only scan?
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Jean-Christophe BOGGIO <postgresql@thefreecat.org>,
	"pgsql-performance@lists.postgresql.org"
 <pgsql-performance@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvogm2ULHZUnmrzX%2BV3QQmB7cVE6%2B8-B91P%2BLcemTQSC9Q%40mail.gmail.com>
Precedence: bulk

On Thu, 18 Sept 2025 at 23:55, Andrei Lepikhov <lepihov@gmail.com> wrote:
> It looks like a makeshift solution. By implementing a callback, we could
> elevate 'interrupter' to a first-class feature, enabling us to monitor
> the state of the entire query tree (it is especially cool in EXPLAIN
> ANALYZE mode when we may be OK with a partial result).
> What's more interesting if Robert's work on nodes' extensibility
> successes, it enables modules to save planning decisions in the plan.
> Thereby, the in-executor callback provides a means to kick off the query
> planned with incorrect estimations (e.g., too many spilled tuples).
>
> Perhaps we should start working on introducing this type of callback/ hook?

I don't really have a fully formed opinion here, but I expect that if
there is something that needs a new hook function, it might be easier
to convince everyone that it's a good idea to accept that change if
you first write a patch to add the hook, then go off and write the
extension that uses it and then come back with that as evidence that
the hook is useful enough to be committed to core.

There's certainly places where you could add a hook that would just
add an unacceptable overhead that we couldn't stomach. I expect
ExecProcNode would be one of those places.

I do agree that trying to come up with something for this is worthy of
some time and effort. Helping people with performance issues when they
can't even get EXPLAIN ANALYZE to finish is quite tricky.

David