Re: [postgis-users] pg_upgrade error: Operator is not unique

Dan, Which schema is your view in? Curious I found this same complaint a while back - https://lists.osgeo.org/pipermail/postgis-users/2012-March/032975.html Well that person had same issue with IS DISTINCT.. and was able to fix by adding the public schema to search_path. So if it's a

[postgis-users] pg_upgrade error: Operator is not unique

Hi All, I'm trying to use pg_upgrade to upgrade a large database from Postgres 9.5 to 9.6, both with PostGIS 2.3.1. The procedure works well except for an error on a single view: pg_restore: [archiver (db)] could not execute query: ERROR: operator is not unique: public.geometry =

Re: [postgis-users] CPU tuning

Well, thanks, could be the explanation. I tried the query but I get SQLSTATE 53200, out of memory after a few seconds. De : postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] De la part de Marcone Envoyé : lundi 9 janvier 2017 15:31 À : PostGIS Users Discussion Objet : Re:

[postgis-users] ST_Clip - Different results between PostGIS 2.0.1 and 2.3.1

Hi there. I'm testing an upgraded database and seeing different results in a query that's using the ST_Clip function. old database: PostgreSQL 9.1.14 with PostGIS 2.0.1 new database: PostgreSQL: 9.6.1 with PostGIS 2.3.1 I know ST_Clip was rewritten in C in PostGIS 2.1. Could this be responsible

Re: [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

Re: [postgis-users] CPU tuning

Hey, option 2 is the fastest one ;-) , option 1 is simply a pure SQL rewrite of your query. The machine I used for test is way weaker than yours (I'd say 2x weaker). 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

Re: [postgis-users] CPU tuning

Hi, Thanks for your answer and this way of calculation. I don't know which machine you have but on mine, Option 1 launched from pgadmin takes 2,564,423 ms (about 45 mn) a bit less than my original code (2,823,272 ms). So if this takes less than 1 second on yours, there is definitively a

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 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,