SEO

I have a math question and a benchmark question and I'm not sure how
to benchmark it.

What I'm trying to do is use pgsql as a bayes token store for a spam
filter I'm writing.
In doing this I have a data structure with index keys and two integer
fields 'h_msgs' and 's_msgs' for each token and another pair for each
user (H_msgs, S_msgs), making four data pieces for each user-token
relationship.

for Bayes these are run through an equation of the form:
(s_msgs/S_msgs)/(s_msgs/S_msgs + h_msgs/H_msgs)
Which I currently do in perl.
In pgsql I have to modify this a bit with 'cast (s_msgs as double
precision)' or 'cast(s_msgs as real)' in order to get floating point
math.
( cast(s_msgs as double precision)/S_msgs) and so on...

Question: Is there a better way to get floating point math out of a
set of integers?

Thought occurred to me that if I let pgsql do this, it should be
considerably faster since perl is slower than C. But I don't know if
I have any good way of proving this.
The data retrieval process tends to dwarf everything else -- which
may mean I really shouldn't waste my time with this anyways.

But I was wondering if the thinking is valid, and how I might
benchmark the differences.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

tom wrote:

> In pgsql I have to modify this a bit with 'cast (s_msgs as double
> precision)' or 'cast(s_msgs as real)' in order to get floating point math.
> ( cast(s_msgs as double precision)/S_msgs) and so on...
>
> Question: Is there a better way to get floating point math out of a set
> of integers?

Nope.

This is mentioned in the docs:
http://www.postgresql.org/docs/8.2/s...ions-math.html

division (integer division truncates results)

I'm sure it's because of sql specs but someone else will throw their
2c's in if that's wrong

You only need one real or double precision field in there for that not
to be truncated, you don't need to cast everything.

--
Postgresql & php tutorials
http://www.designmagick.com/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On 4/26/2007, "Chris" <dmagick@gmail.com> wrote:

>tom wrote:
>
>> In pgsql I have to modify this a bit with 'cast (s_msgs as double
>> precision)' or 'cast(s_msgs as real)' in order to get floating point math.
>> ( cast(s_msgs as double precision)/S_msgs) and so on...
>>
>> Question: Is there a better way to get floating point math out of a set
>> of integers?
>
>Nope.

The way they treat math isn't new. cast one as real and the rest will
follow.

Any idea if it's going to be "better" or even something that can
realistically be benchmarked?

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings