On Apr 26, 2010, at 11:09 AM, Tom Broadbent wrote: > > thanks for the replies. > > understood. i was informed that our underlying (EMMC??) FS will do > this w/ FS pages, i.e. read the entire 256k FS page, modify some > small portion of it, and write it out again. i'm higher in the > stack so i don't understand the underlying FS mechanisms; i've > simply asked the lower-level devs for advice about maximizing FS IO. > > on this particular FS i'm under the impression that writing a 1k > SQLite page requires reading a 256k FS page, modifying the 1k > portion and then writing the whole 256k FS page out. i'll verify w/ > the lower-level devs next week. > > yes, this sounds _very_ inefficient, but perhaps this is why our > commit times are so poor (i.e. writing each DB page requires reading > and writing a much larger FS page). > > yes - i'm aware that each table and index are in a separate DB page; > i saw evidence of this when bumping the page size from 1k to 32k. > > this DB has only one table w/ a single pkey index. the DB will be > relatively large (10MB) compared to the page size and will continue > to grow over time, so i'm not concerned. > > basically i want to know if SQLite will have internal problems > running w/ a page_size greater than the recommended (required?) max > of 32k.
The page formats use 16-bit unsigned integers to store various offsets (in bytes) to cells and free-blocks within a page. So it definitely won't work with greater than 64KB pages. Not sure if 64KB would work or not. Since it hasn't been tested, the answer is probably "No.". Dan. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
