On 17 November 2014 22:27, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Another idea that occurred to me is to run a planning cycle in which the > actual parameter values are made available to the planner, but as > estimates not hard constants (this facility already exists, it's just not > being used by plancache.c). This would yield cost estimates that are more > safely comparable to the custom plan. But I'm not sure that we'd want to > expend yet another planning cycle to do this, nor am I sure that we'd want > to use such a plan as The Generic Plan. > > regards, tom lane Perhaps a somewhat naive idea, I only have the broad picture of how the query planner works, but... What if prepared statements would not store an entirely pinned down version of the query plan, but instead stores a smashed down version of the query plan that still leaves room for choosing some different paths based on key decision criteria? For example, if an input parameter value matches the most common values, choose the sequential scan path (as in the OP's case, IIRC) and if it's not, attempt an index scan. Of course, one implication of doing this is likely a decrease in planning performance (which matters for simple queries), but if it results in better plan choices for complex queries that may be a nett gain. I recently followed an introductory class about neural networks and the decision logic seems to look like the neuron/perceptron pattern. I'm just throwing this out here in case it's a viable option and nobody else in the world thought of this, however unlikely ;) -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
