Re: a path towards replacing GEQO with something better

On Mon, Jun 14, 2021 at 06:10:28PM +0200, Tomas Vondra wrote:
> On 6/14/21 1:16 PM, John Naylor wrote:
> > On Sun, Jun 13, 2021 at 9:50 AM Tomas Vondra
> > <tomas(dot)vondra(at)enterprisedb(dot)com <mailto:tomas(dot)vondra(at)enterprisedb(dot)com>>
> > wrote:
> >
> >> > 2) We can still keep GEQO around (with some huge limit by default) for a
> >> > few years as an escape hatch, while we refine the replacement. If there
> >> > is some bug that prevents finding a plan, we can emit a WARNING and fall
> >> > back to GEQO. Or if a user encounters a regression in a big query, they
> >> > can lower the limit to restore the plan they had in an earlier version.
> >> >
> >>
> >> Not sure. Keeping significant amounts of code may not be free - both for
> >> maintenance and new features. It'd be a bit sad if someone proposed
> >> improvements to join planning, but had to do 2x the work to support it
> >> in both the DP and GEQO branches, or risk incompatibility.
> >
> > Looking back again at the commit history, we did modify geqo to support
> > partial paths and partition-wise join, so that's a fair concern.
>
> Right. I think the question is how complex those changes were. If it was
> mostly mechanical, it's not a big deal and we can keep both, but if it
> requires deeper knowledge of the GEQO inner workings it may be an issue
> (planner changes are already challenging enough).

The random plan nature of GEQO, along with its "cliff", make it
something I would be glad to get rid of if we can get an improved
approach to large planning needs.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.