On Tue, Apr 01, 2008 at 08:17:54PM -0500, Mike Owens scratched on the wall: > The main reason why SQLite's practical limit is in the 10s of GBs as > opposed to TBs (theoretical) is due to how it tracks dirty pages. > [...] > SQLite tracks dirty pages with a bitmap which is > allocated before each transaction. The size of the bitmap is > proportional to the size (not in rows but in pages) of the database
Doesn't the "bitvec" structure introduced in 3.5.7 help with that somewhat? I was under the impression it allowed for sparse bitmaps, which seems like it would be the common case for INSERTs, UPDATEs, and DELETEs. I suppose a huge delete or a DROP [TABLE|INDEX] might still cause the bitmap to get pretty big, but those are more unusual operations. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "'People who live in bamboo houses should not throw pandas.' Jesus said that." - "The Ninja", www.AskANinja.com, "Special Delivery 10: Pop!Tech 2006" _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
