Hi,
I'm not sure ... I thought I ran it on my P4 here in the office and
saw it
too, albeit not near as frequently ... but, in FreeBSD's case, it is a
"design issue" ... there are two different functions, once that is
kinda
fuzzy (but fast), and the other that is designed to be exact, but at a
pe
On Sat, 31 Jan 2004, Tom Lane wrote:
> David Teran <[EMAIL PROTECTED]> writes:
> > Apple provides a little tool that can enable / disable the l2 cache ...
> > one CPU of a dual CPU system on the fly. When i start the testapp with
> > two CPU's enabled i get this output here, when i turn off one CP
David Teran <[EMAIL PROTECTED]> writes:
> Apple provides a little tool that can enable / disable the l2 cache ...
> one CPU of a dual CPU system on the fly. When i start the testapp with
> two CPU's enabled i get this output here, when i turn off one CPU while
> the app is still running the mess
Hi Tim,
you are right:
Interesting. I have recollected where we saw this before:
http://archives.postgresql.org/pgsql-hackers/2003-11/msg01528.php
Apparently gettimeofday() has a glitch on some BSD releases. OS X is
a BSD derivative and it's not so surprising if it has it too.
May I suggest th
David Teran <[EMAIL PROTECTED]> writes:
>> I recall that we saw similar symptoms once before, and I thought we'd
>> fixed it, but I didn't find any relevant mentions in the CVS logs.
>>
>> What version are you running, exactly?
> 7.4.1, build from sourcecode. Running on MacOS X Server 10.3.2, dua
HI Tom.
I got a little distracted by the bizarre actual-time values shown for
some of the query steps:
-> Merge Join (cost=2451266.53..2655338.83 rows=13604393
width=8)
(actual time=82899.466..-2371037.726 rows=2091599 loops=1)
-> Sort (cost=2451169.10..2483246.47 rows=12830947
On Friday 30 January 2004 19:19, Tom Lane wrote:
>
> The hash-join total time is obviously wrong seeing that the total
> runtime is only about 10 msec, and the negative values for the other
> two are even more obviously wrong.
>
> I recall that we saw similar symptoms once before, and I thought
David Teran <[EMAIL PROTECTED]> writes:
> [ query plan ]
I got a little distracted by the bizarre actual-time values shown for
some of the query steps:
> -> Merge Join (cost=2451266.53..2655338.83 rows=13604393 width=8)
> (actual time=82899.466..-2371037.726 rows=2091599 loops=1)
>
Hi,
On 30.01.2004, at 19:10, Stephan Szabo wrote:
On Fri, 30 Jan 2004, David Teran wrote:
select
sum(job_property_difference(t0.int_value, t1.int_value)) as rank
from
job_property t0,
job_property t1
where
t0.id_job_profile = 911
and t0.id_job_attribute = t1.id_job_attribute
On Fri, 30 Jan 2004, David Teran wrote:
> select
> sum(job_property_difference(t0.int_value, t1.int_value)) as rank
>from
>job_property t0,
>job_property t1
>where
>t0.id_job_profile = 911
>and t0.id_job_attribute = t1.id_job_attribute
>and t1.id_job_profile in (select
On Jan 30, 2004, at 11:00 AM, David Teran wrote:
executing a select like this:
select
sum(job_property_difference(t0.int_value, t1.int_value)) as rank
from
job_property t0,
job_property t1
where
t0.id_job_profile = 911
and t0.id_job_attribute = t1.id_job_attribute
and t1.id_job_profi
Hi,
its me again. As far as we tested postgresql ist fast, very fast
compared to the other db system we test and are using currently.
We are now testing some test databases on Postgres. We use one
function which simply calculates a difference between two values and
checks if on value is 0,
12 matches
Mail list logo
