Tom Lane wrote:
The infrastructure for the former planning method (using the first
Bind's parameters as sample values for estimation, but not as constants)
is still there, but it's not being used now. Does anyone want to argue
for changing things to plan named statements that way? I'm of two
Although I don't have a clear opinion myself, I sometimes read on this list
that people are using prepared statements to get safe, stable plans, i.e.
plans that don't depend on the specific parameter input.
I definitely want the possibility of getting stable plans. That's only
possible if
I wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
I believe this could usefully (and transparently to clients) be changed
so that Bind on the unnamed statement does _not_ store the plan back in
the unnamed statement's context, but instead produces a plan which is
only used _for that
Picking out a specific point from the thread on prepared queries:
Currently, the handling of Parse/Bind on the unnamed statement seems to
go like this:
- Parse on the unnamed statement does analysis and rewriting but does
not plan, storing the query in a special memory context dedicated to
Andrew - Supernews [EMAIL PROTECTED] writes:
I believe this could usefully (and transparently to clients) be changed
so that Bind on the unnamed statement does _not_ store the plan back in
the unnamed statement's context, but instead produces a plan which is
only used _for that specific
