"Marc G. Fournier" <scrappy@postgresql.org> 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?
> 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.57rows=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?
regards, tom lane