[rttopo-dev] reserving face identifiers for state flags

[Brian M Hamlin]

As far as I know, a DELETE should be cheap, since the ROW is just marked for deletion

UPDATE is very expensive, and for large tables and large sets, a complete rewrite (new table) is faster

VACUUM is slow and can occur anytime, especially after a DELETE
I suspect you are seeing a VACUUM ?

  just a guess, hth
   --Brian




On Wed, 14 Sep 2016 17:39:57 +0200, Sandro Santilli  wrote:

On Wed, Sep 14, 2016 at 03:04:06PM +0200, Sandro Santilli wrote:

> As a backend might refuse to allow a _face value which does not
> exist in the  table, the library also creates a "placeholder"
> face there with the hard-coded identifier.  Shall the backend topology
> already have a face with the hard-coded value for "unassigned face",
> the backend would raise an exception there, making the process fail.

I'm witnessing a very long time spent by PostgreSQL processing
a DELETE, during a topology.RegisterMissingFaces call.
As the only expected DELETE is deletion of the placeholder
face, I'm now wondering if it makes sense to avoid using
the backend for state completely :(

It's hard to know what to expect by different backends, especially
as the library is not in charge of creating foreign keys and
the like on the actual tables...

--strk;
_______________________________________________
librttopo-dev mailing list
librttopo-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/librttopo-dev