> Le 7 juil. 2018 à 17:52, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > Arnaud, > a couple of other thoughts.... > - are any/all of the related tables very large in record count size? this > might be a cache thing... > maybe 4D is 'thrashing' loading indexes etc, then having to throw them away > for the next table(s) and then loading them again. > -- you might be able to see/test this by watching/adjusting the cache, and/or > watching disk usage. > - alternatively, maybe for some (unexplainable) reason 4D is NOT using the > index(es) and/or relation directly and doing a sequential search on each > related table. > -- you might be able to test this by using test data which has a small number > of records in the related tables, and then add more and more seeing if the > deletion slows down (linearly?).
Side 1 table is 2.7 billion records, side N the same, ~10 records without sons to delete on side 1, worked during years. As it became suddenly very slow with a cache like sawtooth wave, I agree it looks like a threshold effect in deletion control. When I remove deletion control, control there is no sons (query) and delete by myself (delete selection), it's instantaneous. It shows that the problem occurs when 4D is checking there are no sons. -- Arnaud ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
