On Mon, September 4, 2006 23:03, Tom Lane wrote:
> Ah. I think you're confusing the spectators by using "predict" when you
> should say "match". You're looking for previously generated plans that
> have assumed parameter values matching the current query --- saying that
> the plan "predicts" a parameter value is just a really poor choice of
> wording.
I guess so... It's been over a decade since I last busied myself with
database optimization, so I don't know any of the jargon. Had to use
processor architecture jargon instead.
So with that out of the way, can anyone think of some good real-life
examples of prepared statement usage that I can test against? Suggestions
I've had include TPC, DBT2 (based on TPC-C), and pgbench, but what I'm
really looking for is traces of invocations by real applications.
If we don't have a body of application traces available, can anyone think
of a convenient, nonintrusive way I could extract them out of applications
I'm running? If there is, I could write a filter to eliminate irrelevant
information. The filter would ignore everything other than prepared
statement invocations. It could randomize statement names, strip out
their definitions, hide the ordering between different statements, and
replace parameter values with meaningless numbers; so it would be
relatively safe for others to volunteer traces of their own applications.
None of those transformations would affect my simulation results.
Jeroen
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
