"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Fri, 28 Nov 2003, Tom Lane wrote:
>> 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 :)
Well, it's not reproducibly negative, but it seems reproducibly wrong:
Aggregate (cost=40168.96..40168.96 rows=1 width=4) (actual time=49641.603..49641.611
rows=1 loops=1)
-> Seq Scan on ndict3 (cost=0.00..34560.57 rows=2243357 width=4) (actual
time=34.854..724754.474 rows=3570252 loops=1)
Total runtime: 49688.524 ms
Aggregate (cost=40168.96..40168.96 rows=1 width=4) (actual time=36625.013..36625.018
rows=1 loops=1)
-> Seq Scan on ndict3 (cost=0.00..34560.57 rows=2243357 width=4) (actual
time=0.128..-676113.173 rows=3572298 loops=1)
Total runtime: 36625.779 ms
Aggregate (cost=40168.96..40168.96 rows=1 width=4) (actual time=41380.881..41380.885
rows=1 loops=1)
-> Seq Scan on ndict3 (cost=0.00..34560.57 rows=2243357 width=4) (actual
time=0.091..718200.092 rows=3575264 loops=1)
Total runtime: 41381.504 ms
(3 rows)
I'm wondering if there's an actual bug in gettimeofday() in this
platform, such that once in a while it returns a value that's off
a minute or so ...
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
