Re: [HACKERS] Performance issue with libpq prepared queries on 9.3 and 9.4

On 17 November 2014 22:27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.