Maybe more work, but: Could a custom plan be cached /along with the values of the parameters for which it was planned/? Then it's kind of a no-brainer to say "if the parameters are the same this time, I'm probably looking at the best plan already." Pretty simpleminded, but at least it would catch the testcase where the plan flips to a bad one even when literally the very same parameters are used.
Generalizing a little, how about caching a plan along with a boolean expression tree over the parameters, evaluating to true if the new parameters are "close enough" to the planned ones so that the plan is probably still better than generic? Version zero could just create the expression p1 = oldp1 AND p2 = oldp2 AND p3 = oldp3, and be simply the same as the first suggestion. But then, how to generate more interesting and useful validity-expressions for different plan types and statistics could be a future-work area with some meat to it, promising successive improvements. Maybe plugins could supplement it for particular characterized workloads.... -Chap On 01/13/2016 08:28 AM, Marko Tiikkaja wrote: > On 13/01/16 14:12, Pavel Stehule wrote: >> so the strategy - if cost of generic plan is less than some MAGIC >> CONSTANT >> (can be specified by GUC), then use generic plan. Elsewhere use a custom >> plan everytime. >> >> It allow to controll the plan reusing. When MAGIC CONSTANT = 0 .. use >> custom plan everytime, When MAGIC CONSTANT = M, then use generic plan >> always. > > I don't think that would solve even the original problem without > effectively disabling generic plans, despite the problem being > relatively simple. The generic plan appears to be really cheap, because > the planner doesn't have the concept of a "worst case". > > > .m > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
