>(1) the generic plan is falsely optimistic That is my case. Application is sending most common value on every execution while backend is optimistic and it things that the app would stop sending MCVs.
Costs for the plans are OK. However, there is a data skew, so it is hard to tell what is the "true" selectivity of the skewed column in general, thus the discussion. VS>>In other words, application developer should understand VS>> if a query is DWH-like (requires replans) or OLTP-like (does not VS>> require replans). Agreed? Tom>No, not agreed. As was already pointed out upthread, such information Tom>is not available in many use-cases for the plancache. I think you answer the wrong question. I was asking if you agree that _application_ developer (not pg backed developer) should know if a query is OLTP or DWH like. Do you really think app developer should not care which plan would be chosen for a particular query he is working on? Why all that "explain" stuff in documentation then? In the plancache.c you have CURSOR_OPT_GENERIC_PLAN and CURSOR_OPT_CUSTOM_PLAN flags. It is obvious that those flags are not yet exposed/used by applications, but my message is that "one should *not* think that DB has artificial intelligence to properly identify a plan for each bind sets and cache plans at the same time". Vladimir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers