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.von...@enterprisedb.com <mailto:tomas.von...@enterprisedb.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 <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
