Nikolaus Rath wrote: > The only two ideas that come to my mind is to use a random search like > sqlite uses for the rowid, or to store the unused values in an > additional table. But I have serious doubts about both solutions. While > random search may have a good chance of success if there are 2^64 > possible rowids (it's very unlikely that more than half of them are > used, since that would already take up 8192 Petabyte), I don't think it > works very well for 2^32 possible values (when there may well be only a > couple of hundred unused ones). Using an additional table to store > unused values would require me to initialize this table with the first > 2^32 integers (taking up about 4 GB) when the main table is empty, which > is rather crude. > > The perfect solution would be to tell SQLite that it should restrict the > rowid to 2^32, but I couldn't find a documented way to do that.
Didn't you just say that the algorithm SQLite uses for rowid wouldn't work for your situation? So you think it wouldn't work if you implement it, but should magically work if SQLite implements it? Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
