Could we come up with a compromise then? I guess maybe another setting that says log any query when it hits more than x amount of time. (I'd also argue you should get a NOTICE or WARNING when this exceeds the query timeout time).
A perhapse more friendly alternative would be a way to query to get this information in real-time, but that probably goes back into the discussion about the length of data made available in pg_stat_activity. On Tue, Nov 30, 2004 at 02:32:05PM -0500, Bruce Momjian wrote: > David Parker wrote: > > I've been using "log_min_duration_statement = 0" to get durations on all > > SQL statements for the purposes of performance tuning, because this logs > > the duration on the same line as the statement. My reading of this TODO > > is that now log_min_duration_statement = 0 would give me the statements > > but no total duration? > > Oh, sorry, you are right. I forgot about the duration part! I got so > excited I forgot. > > TODO item removed. > > -- > 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 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
