> > 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
