<div dir="ltr"><div dir="ltr">Nuno and list<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 2, 2020 at 11:58 AM Nuno Lopes <<a href="mailto:nlopes@gmail.com">nlopes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello, I have already posted this on <a href="https://gis.stackexchange.com/questions/360171/adding-feature-to-postgis-layer-that-has-joins-is-really-slow" target="_blank">https://gis.stackexchange.com/questions/360171/adding-feature-to-postgis-layer-that-has-joins-is-really-slow</a> , just posting here to see if someone else has ideas.</div><div><br></div><div>I have a large project that I've been setting up to work with QGIS 3.12 and I have now hit a problem with using "joins" to join several attribute tables with a geometric one.<br><br>I have reduced the problem to a minimal setup that has only two layers with a one to one (or zero) relation:<br><br> 1. `point_layer` - a layer with a geometry (points) that has 64k entries<br> 2. `attribute_layer` - a layer with one text field and a foreign key to the `point_layer`<br><br>On the `point_layer` I added a join to the `attribute_layer` so that we can edit the attributes directly in the feature form.<br><br>After doing this whenever I try to create a point on the `point_layer` **it takes more than 1 min to create the feature**.<br><br>By examining the PostgreSQL log I found out that QGIS is querying each feature on the `point_layer` for it's relation on the `attribute_layer`. These queries are made one by one, so even though I'm running the database on my own computer, the sheer number of queries leads to very poor performance.<br><br>I've already tried tweaking the cache config on the joins, hiding the form on add feature and enabling the "automatically create transaction groups where possible" to no avail.<br><br>I've also tested older QGIS versions 3.4 and 3.8 without success.<br><br>Am I doing anything wrong? Is there any way to work around this?</div><div><br></div><div>The schema used is:<br></div><div><br>    CREATE TABLE point_layer (<br>        ogc_fid integer PRIMARY KEY,<br>        geom public.geometry(GeometryZ,3763),<br>        height double precision<br>    );<br>    <br>    CREATE INDEX point_layer_geom_idx ON point_layer USING gist (geom);<br>    <br>    CREATE TABLE attribute_layer (<br>        id SERIAL PRIMARY KEY,<br>        fid integer REFERENCES point_layer(ogc_fid),<br>        some_value text<br>    );<br><br>The query that is made repeatedly is (the fid changes):<br><br>    SELECT "id","some_value"::text,"fid"::text <br>    FROM "public"."attribute_layer" <br>    WHERE ("fid" = ?) LIMIT 1<br><br>The explain analyze is (the table is empty):<br><br>                                                      QUERY PLAN                                                   <br>    ---------------------------------------------------------------------------------------------------------------<br>     Limit  (cost=0.00..4.17 rows=1 width=68) (actual time=0.014..0.014 rows=0 loops=1)<br>       ->  Seq Scan on test_relation  (cost=0.00..25.03 rows=6 width=68) (actual time=0.011..0.011 rows=0 loops=1)<br>             Filter: (fid = 29853)<br>     Planning Time: 0.506 ms<br>     Execution Time: 0.086 ms<br></div><div><br></div><div><br></div><div><br></div></div></blockquote><div>Why not just put your attributes on the same table as the spatial one?</div><div><br></div><div>If you don't like that idea you could consider putting an index on the fid on the attribute_layer.  But it's odd to me to see the select on the attribute_layer table given that your fid in your attribute_layer is a foreign key referencing the ogc_fid field in point_layer.<br></div></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Chris Hermansen · clhermansen "at" gmail "dot" com<br><br>C'est ma façon de parler.</div></div></div>