Re: Why isn't PG using an index-only scan?
От | David Rowley |
---|---|
Тема | Re: Why isn't PG using an index-only scan? |
Дата | |
Msg-id | CAApHDvogm2ULHZUnmrzX+V3QQmB7cVE6+8-B91P+LcemTQSC9Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Why isn't PG using an index-only scan? (Andrei Lepikhov <lepihov@gmail.com>) |
Список | pgsql-performance |
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
В списке pgsql-performance по дате отправления: