Richard Hipp-3 wrote > DROP, CREATE, and ALTER are transactional in SQLite, just like DELETE, > INSERT, and UPDATE. This has always been the case, and always shall > be.
Thanks! But still, isn't this incompatible with any lower-than-DB-level transaction locking mechanism? I.E. should you ever have row-level locking, this absolutely needs a persistent, cross-connection ROWID index; while any FOR UPDATE locking semantics need persistent gap-locking indexes... Just a thought for the distant future, I realize it's not a discussion to have now :) Keith Medcalf wrote > pragma cache_size=262144; -- 1 GB page cache Actually I realized that the DB page size is 1K. Is this bad? I tried to run the pragma query with 1M pages, to amount to the same 1G; there seems to be a dramatic improvement in throughput at the beginning of the query, but it quickly succombs to nonlinear slow-down-to-a-drag nonetheless. Richard, leaving alternate strategies aside (DROP, TRUNCATE etc.), what could be the reason behing this non-linear delete behavior? Why does it slow down to a grinding halt? It would be tremendously helping for me to know; we are in the process of migrating more than just this table to SQLite so knowledge about the inner workings of SQLite helps us tremendously. Thanks! -- Sent from: http://sqlite.1065341.n5.nabble.com/ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
