OK, I added this TODO:
* Allow finer control over the caching of prepared query plans
Currently, queries prepared via the libpq API are planned on first
execute using the supplied parameters --- allow SQL PREPARE to do the
same. Also, allow control over replanning prepared queries either
Bruce Momjian wrote:
Oliver Jowett wrote:
Bruce Momjian wrote:
Oliver Jowett wrote:
Merlin Moncure wrote:
Another way to deal with the problem is to defer plan generation until
the first plan execution and use the parameters from that execution.
When talking the V3 protocol, 7.5 defers plan gener
Oliver Jowett wrote:
> Bruce Momjian wrote:
> > Oliver Jowett wrote:
> >
> >>Merlin Moncure wrote:
> >>
> >>
> >>>Another way to deal with the problem is to defer plan generation until
> >>>the first plan execution and use the parameters from that execution.
> >>
> >>When talking the V3 protocol,
Bruce Momjian wrote:
Oliver Jowett wrote:
Merlin Moncure wrote:
Another way to deal with the problem is to defer plan generation until
the first plan execution and use the parameters from that execution.
When talking the V3 protocol, 7.5 defers plan generation for the unnamed
statement until para
Oliver Jowett wrote:
> Merlin Moncure wrote:
>
> > Another way to deal with the problem is to defer plan generation until
> > the first plan execution and use the parameters from that execution.
>
> When talking the V3 protocol, 7.5 defers plan generation for the unnamed
> statement until parame
Merlin Moncure wrote:
Another way to deal with the problem is to defer plan generation until
the first plan execution and use the parameters from that execution.
When talking the V3 protocol, 7.5 defers plan generation for the unnamed
statement until parameters are received in the Bind message (wh
On Wed, 2004-07-21 at 19:12, Merlin Moncure wrote:
> There is one problem with the optimizer that is a constant source of
> frustration. When using prepared statements and functions (particularly
> where function parameters are passed to a query), the optimizer often
> fails to utilize an index in
Merlin Moncure wrote:
Merlin,
This will most likely never be accepted by the core team because it is
better to spend more time on fixing the planner than to invent some
non-standard.
As far as I know some databases support a syntax where hints can be
hidden in comments or something like that.
Meanw
There is one problem with the optimizer that is a constant source of
frustration. When using prepared statements and functions (particularly
where function parameters are passed to a query), the optimizer often
fails to utilize an index inside a plan.
This is a well known problem because the pa