On Fri, 28 Nov 2003, Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > did you happen to take a look at the other set of queries I sent you, that > > were showing 39k and 41k explain results? > > You mean this one?
Yup ... > > time psql -c "explain analyze select max(intag) from ndict3" 186_archives > QUERY PLAN > ---------------------------------------------------------------------------------------------------------------------------- > Aggregate (cost=40168.96..40168.96 rows=1 width=4) (actual > time=48953.823..48953.827 rows=1 loops=1) > -> Seq Scan on ndict3 (cost=0.00..34560.57 rows=2243357 width=4) (actual > time=4.903..-666785.605 rows=3516680 loops=1) > Total runtime: 48982.514 ms > (3 rows) > > 0.000u 0.005s 0:49.06 0.0% 0+0k 0+0io 0pf+0w > > time psql -c "select max(intag) from ndict3" 186_archives > max > ------------ > 2147418368 > (1 row) > > 0.000u 0.005s 0:03.06 0.0% 0+0k 0+0io 0pf+0w > > This looks like 46 seconds of overhead for 3516680 rows, or still right > about 13 microseconds per row, so that's consistent. The negative > "actual time" measurement for the Seq Scan row seems pretty broken > though :-(. > > Now that I recall, didn't you complain of something similar with a beta? Yup ... and I bet its not reproducible yet again, is it? :) That would make for twice though, with v7.4, that I've come up with - results :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
