Hitoshi Harada writes:
> 2011/4/27 Tom Lane :
>> Joel Reymont writes:
>>> That's a 30x speedup, from 12 minutes down to 38s. Thanks Tom!
>> Huh, I would've bet on a lot more actually. The nodeFunctionscan and
>> nodeAgg code must not be as inefficient as it looks on the surface ...
> Did you m
2011/4/27 Tom Lane :
> Joel Reymont writes:
>> On Apr 26, 2011, at 5:00 PM, Tom Lane wrote:
>>> For another couple orders of magnitude, convert the sub-function to C code.
>>> (I don't think you need
>>> a whole data type, just a function that does the scalar product.)
>
>> That's a 30x speedup,
Joel Reymont writes:
> On Apr 26, 2011, at 5:00 PM, Tom Lane wrote:
>> For another couple orders of magnitude, convert the sub-function to C code.
>> (I don't think you need
>> a whole data type, just a function that does the scalar product.)
> That's a 30x speedup, from 12 minutes down to 38s.
Tom,
On Apr 26, 2011, at 5:00 PM, Tom Lane wrote:
> For another couple orders of magnitude, convert the sub-function to C code.
> (I don't think you need
> a whole data type, just a function that does the scalar product.)
That's a 30x speedup, from 12 minutes down to 38s. Thanks Tom!
Joel Reymont writes:
> I'm trying to optimize the following query that performs KL Divergence [1].
> As you can see the distance function operates on vectors of 150 floats.
> CREATE OR REPLACE FUNCTION docs_within_distance(vec topics, threshold float)
> RETURNS TABLE(id doc_id, distance float)
Folks,
I'm trying to optimize the following query that performs KL Divergence [1]. As
you can see the distance function operates on vectors of 150 floats.
The query takes 12 minutes to run on an idle (apart from pgsql) EC2 m1 large
instance with 2 million documents in the docs table. The CPU i
