> > 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. Gavin ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
