> for one custom plans can be much better than the generic plan, independent of > cardinalities
So what? I do not suggest dropping custom plans entirely. I perfectly understand there are cases when better replan every time. > consider e.g a table with one somewhat common and otherwise just unique > values. So what? If I understand you properly, you mean: "if client sends unique binds first 5-6 executions and bad non-unique afterwards, then cached plan would be bad". Is that what you are saying? I agree that is the corner-case for my suggestion. Is is really happening often? I state the following: 1) It is way easier to debug & analyze. For instance: current documentation does *not* list a way to get a *generic plan*. Is that obvious that "you just need to EXPLAIN ANALYZE EXECUTE *6 times in a row*" just to get a generic plan? 2) It is likely to be more performant. We just need to explain users that "if different plans required, just use different statements". Isn't that obvious? Frankly speaking, I do not like "plug&pray" kind of code that just sends bind values and expects magically optimized plan for each bind combination. 3) What about "client sends top most common value 5 times in a row"? Why assume "it will stop doing that"? I think the better assumption is "it will continue doing that". At the end, if a client wants specific treatment of a query, then he/she might be better using separate server-prepared statements (the one for "unique values", and another one for "non-unique"). Vladimir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
