Re: detecting poor query plans

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
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073