Things like pre-parsed prepared statements that're re-planned on every execution are often proposed as solutions to this. This has me wondering: rather than expensively re-planning from scratch, would it be possiblet to adjust the planning process so that *multiple* alternative plans would be cached for a query, using placeholders for unknown rowcounts and costs? At execution, the unknown costs would be filled in and the plans compared then the best plan picked for this execution. Is this crazy talk, or could it significantly reduce the cost of re-planning parameterized prepared statements to the point where it'd be worth doing by default?
Its a good suggestion of some kind of optimization at the server side.
This idea can be extended to an "auto-prepare" mode (like an auto-commit
mode that we have today in Postgres).
But its not so hard to let the application (or library) to decide what to use in
different cases: prepared statement or regular statement. Thus, I think it is
