>Basically you're arguing to fix one specific edge case which bugs you >personally, by creating a lot of others, which don't bug you. Not >convincing.
It bugs me. It bugs clients of pgjdbc (e.g. Thomas who started the thread). Note: support of prepared statements for java applications has just landed. The release dates are 2015-08-27 for pgjdbc, and 2014-02-24 for pgjdbc-ng. I think current report is just a tip of the iceberg. > by creating a lot of others, which don't bug you I think it will not create "lots of others". Do you have any statistics why particular flavour of generic plan was committed in 9.2? Suppose there are two type of binds: "non_unique" (N) and "unique" (U) that require different plans for perfect response times. I see the following sequences UUUUUUUU -- all clear, all the approaches would converge to plan for "unique values". NNNNNNNN -- query for non-unique value is executed again and again. Perfect optimizer would either replan or reuse plan with regard to "MCV" Current behaviour would switch to "optimistic" plan at 6th iteration. It is the case of the thread. My suggestion is to learn that "MCV is used -> use plan optimized for MCV" ^^^ note that above are "recommended" uses of the database. Each statement is used for its own purpose: one for MCVs, another for "good values". Then there are cases of mixed executions. Note: I state that mixing "kinds" of bind values is a bad application design anyway. In other words, application developer should understand if a query is DWH-like (requires replans) or OLTP-like (does not require replans). Agreed? NNNNNUUUUUUU Current behavior optimized for exactly this pattern. Well, why was it chosen over "UUUUUNNNNNNN"? In other words, a pattern like UUUUUNNNNNNN would "create a lot of others" as you say. NUNUNUNUNUN -- perfect optimizer would replan every time (or have two sets of plans, but let's leave that out) Neither my suggestion nor current behaviour properly covers the case. I suggest to spare "NNNNNUUUUUUU" pattern in order to improve "NNNNNNNN". Vladimir -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers