Re: Avoiding bad prepared-statement plans.

> The only case that I think still has any merit is where you get a
> significantly better plan with known parameter values than without.
> The projected-cost threshold might be a reasonable approach for
> attacking that, ie, if estimated cost of generic plan exceeds X
> then take the time to build a custom plan instead. I'm not sure that
> really will fix the problem, but it would be a very simple change to
> make to see how much it helps people.
>
> regards, tom lane
>

It will definitely help with partitioned tables. It's very common case when
raw data taken from hardware stored in single table first, and later we start
to make partitions for each month/week/day. Feature can improve performance
transparently to client apps.

regards,
Dmitry

> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>