I don&#x27;t see how my objections are impossible.<p>On EXPLAIN, if you&#x27;ve passed my example PLANS=3 it would first do the plan in its usual way, and then try optimizing several more times, with some chance of randomly making suboptimal decisions at various decision points.  It would keep doing this until it either had enough plans or else was making essentially random decisions and still couldn&#x27;t find more.<p>I can see this requiring a significant refactor of existing code, but stochastically exploring &quot;pretty good&quot; plans doesn&#x27;t require facing the whole tree of possible plans.<p>The DBA hopefully can recognize the desired plan if it turns up.<p>As for the PLAN command, I do not see the problem.  I can look at the query and the EXPLAIN output, and I can figure out exactly how and where that query&#x27;s conditions are being incorporated.  You might need extra output from EXPLAIN to make it always possible to do in an automated way, but it should be possible.<p>Put another way, you propose that the database has a way to look at the query and a plan stored in the table and figure out how to execute that plan for that query.  What would that table contain that couldn&#x27;t be represented as a chunk of text supplied with a PLAN command?