: [postgis-users] CPU tuning
2017-01-09 12:21 GMT-02:00 Rémi Cura :
postgres 9.4 is non-parallelised, what you see is that postgres use 100% of a
core, but the core beig used is rotated,
which mean the average usage of your cpu is 100% / 4 (your number of core),
which might be the explaination for
2017-01-09 12:21 GMT-02:00 Rémi Cura :
> postgres 9.4 is non-parallelised, what you see is that postgres use 100%
> of a core, but the core beig used is rotated,
> which mean the average usage of your cpu is 100% / 4 (your number of core),
> which might be the explaination for your 30%.
>
Exactly
lists.osgeo.org] *De
> la part de* Rémi Cura
> *Envoyé :* lundi 9 janvier 2017 10:52
> *À :* PostGIS Users Discussion
> *Objet :* Re: [postgis-users] CPU tuning
>
>
>
> Hey,
>
> I
>
> 'm afraid you may not use the most efficient approach.
>
> Assuming you wa
mailto:postgis-users-boun...@lists.osgeo.org] De la part de
Rémi Cura
Envoyé : lundi 9 janvier 2017 10:52
À : PostGIS Users Discussion
Objet : Re: [postgis-users] CPU tuning
Hey,
I
'm afraid you may not use the most efficient approach.
Assuming you want to find for each node of table x
Hey,
I
'm afraid you may not use the most efficient approach.
Assuming you want to find for each node of table x the closest node of
table y,
it takes less than 1 second on my computer.
DROP TABLE IF EXISTS test_1;
CREATE TABLE test_1 AS
SELECT s AS gid, ST_makePoint(random()*1000,random()*1
Hi,
I have a pgsql postgis function that last about an hour on an Hp Envy (W10,
i7-6500 CPU 2,5 Ghz 8go). This function is calculating minimum distance
between each nodes of table x (12000 nodes) and table y (42000 nodes)
FOR row IN
SELECT code,ST_AsEwkt(ST_StartPoint(geom