It may not look like a sexy marketing feature.  But it is the #1 reason why I don&#x27;t recommend PostgreSQL.<p>I also don&#x27;t think that query hints are a good way to do it.  And I don&#x27;t mind if the way to do it is somewhat cumbersome.  This is very much a case where 20% of the work can give 99% of the benefit.<p>For example what about the following approach?<p>1. Add an option to EXPLAIN that will cause PostgreSQL&#x27;s optimizer to spit out multiple plans it considered, with costs, and with a description of the plan that PostgreSQL can easily parse and fit to a query.<p>2. Add a PLAN command that can be applied to a prepared statement and will set its plan.  It is an error to submit a plan that does not match the query.<p>And now in the rare case where I don&#x27;t like a query&#x27;s plan I can:<p><pre><code>    EXPLAIN PLANS=3 (query);
</code></pre>
Pick my desired plan from the list (hopefully)<p>Then in my code I:<p><pre><code>    PREPARE foo AS (query);
    PLAN foo (selected plan);
    EXECUTE foo;
</code></pre>
And now if I notice that a query performs worse than I think it should, I can make it do what I want it to.