Mark Mielke <m...@mark.mielke.cc> writes:
> Will "guessing" at when the user can afford to wait longer improve the
> situation? Maybe or often, but not always.
There is no way to eliminate "guessing". The entire point here is that
we don't know whether generating a custom plan will provide a win over
not doing so, until after we've done it (and already taken the planning
time hit). We could possibly put in heuristic tests based on the
query's use of certain features; but that's still guessing, and would
take nonzero time in itself.
I concur with Jeroen's feeling that going for a simple approach first
is the way to attack this. We could design and build something vastly
more complex, then find out that it doesn't actually work much better.
Also, I think there is a lot of confusion here over two different
issues: generic plan versus parameter-specific plan, and bad planner
estimates leading to a wrong plan choice. While the latter is certainly
an issue sometimes, there is no reason to believe that it affects
prepared statements worse than non-prepared ones. So I think that
designing a fix for prepared statements on the assumption that you can't
trust the planner's estimates is solving the wrong problem.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
