On 4/4/26 05:14, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> 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/78dd9572-7569-4025-984d-e07d7f381b6e@gmail.com
[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
