On 4/4/26 05:14, Tom Lane wrote:
Robert Haas <[email protected]> writes:
The terms that I'm thinking in are "how much redesign will we accept
post-feature-freeze, in either pg_plan_advice or test_plan_advice,
before choosing to revert those modules entirely for v19?". I think
that running those tests serially is a sufficiently low-risk option
that it'd be okay to put it in post-freeze, even very long after.
I'm not sure that any of the other group-1 or group-2 options you
suggested would be okay post-freeze. (Of course, ultimately that'd
be the RMT's decision not mine.)
I believe that we probably will need to do something in this
area before v19 release. If we're willing to commit to it being
"run the tests serially", then sure we can wait awhile before
actually doing that. Maybe we'll even think of a better idea
... but what we can do about this post-freeze seems pretty
constrained to me.
As you work on the code, please keep the pg_plan_advice issue [1] in
mind. I came across it while designing the optimisation in [2]. Even if
[2] is not added to the Postgres core, this still looks like a valid
query plan and may be proposed by an extension. So, the hinting module
should avoid conflicts with other extensions, just as pg_hint_plan does.
[1] pg_plan_advice fails when NestLoop outer side is Sort over FunctionScan
https://www.postgresql.org/message-id/[email protected]
[2] Try a presorted outer path when referenced by an ORDER BY prefix
https://www.postgresql.org/message-id/19a9265c-c441-4a43-bc0d-dac533438da0%40gmail.com
--
regards, Andrei Lepikhov,
pgEdge
