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