On 1 May 2010, at 12:56, Alban Hertroys wrote: > You could argue that some logic could be added to the handling of prepared statements to insert query-subplans depending on what data you use for your parameters, but then you're moving back in the direction of unprepared statements (namely invoking the query planner). It would help cases like this one, but it would hurt all other prepared statements. It would at the least add a parse tree back into the queries path, which would be a fairly simplistic one in the case of table partitioning, but would get fairly complex for prepared statements involving more parameters - so much so that the benefit of using a prepared statement (not spending time planning the query) would get reduced significantly. And of course it would add time for planning the query-tree to the creation of the prepared statement - which could be significant compared to the time people expect to save by not invoking the planner on later invocations of the same query. That said, the more frequent the query is executed the less that hurts performance, while it doesn't really matter for queries that are executed infrequently. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:737,4bdc0ba010411331128920! -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
