Simon Riggs wrote: > ISTM we could do some of that with another GUC, lets call it > prepare_once = on. The system default is to have a prepared statement > bound to a plan on its first parameter bind. If we set this to "off", > then the statement will replan each time we bind. This would give us > both flexibility and predictability. (As ever, someone suggest a better > name?).
Why would all statements behave the same? I think an important percentage of cases would require a fixed plan (thus planning at first sight is a good idea), while a limited number of cases would require planning every time the sentence is called. Your idea of qualifying it by table name does not make too much sense to me, because you can have both types of queries for each table, and further any query where this is necessary will involve more than one table anyway, so which one do you choose to make the decision? So we would provide a protocol/libpq option to allow first-params- planning (the default and current behavior), and another to allow planning-every-time. The latter would tell the server to save only the parsetree of the query and replan each time it is invoked. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
