Gavin Sherry wrote: > > > On further thought the real problem is that these numbers are only available > > > when running with "explain" on. As shown recently on one of the lists, the > > > cost of the repeated gettimeofday calls can be substantial. It's not really > > > feasible to suggest running all queries with that profiling. > > > > Yeah. You could imagine a simplified-stats mode that only collects the > > total runtime (two gettimeofday's per query is nothing) and the row > > counts (shouldn't be impossibly expensive either, especially if we > > merged the needed fields into PlanState instead of requiring a > > separately allocated node). Not sure if that's as useful though. > > How about a PGC_POSTMASTER GUC variable which tells postgres to collect > details on the planner's performance and comparison to actual run times. > Optionally, we could also have the executor run some/all of the possible > plans (presumably only useful for SELECTs) and keep details on the > performance of each. At postmaster shutdown (some other time?) a report > could be produced profiling all queries. > > The reason I suggest this is it would have zero impact on production > databases but would allow DBAs to profile their databases with real usage > patterns in development environments.
Great idea. Under ideal situations, it shouldn't be needed, but things are often less than idea. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
