"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?
> 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?
regards, tom lane
---------------------------(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
