Dennis Cote <[EMAIL PROTECTED]> wrote:
>
> Richard,
>
> How was the current default page size of 1K determined? Was there any
> testing to see if larger page sizes would be beneficial for general use?
> Or is it just a historical circumstance (i.e. an arbitrarily chosen
> value that has been maintained for backwards compatability)?
>
> I'm thinking the "usual" case may be changing as available storage gets
> larger, and users start storing more and larger BLOBs in the database.
>
Experiments with version 2.0.0 shows that 1KiB was fastest
on Linux.
Since version 3.5.0, SQLite will sometimes choose a larger
default page size. The size choosen is the largest of:
* 1024 bytes
* The "sector size" as reported by the VFS layer
* The largest size that can be written atomically
In the current implementations for win32 and unix, the
sector size is hard-coded to 512. (This may need to change
in the future with newer 2048-byte sector disk drives.)
And both interfaces assume writes are never atomic. So
the default still ends up being 1024. But the mechanism
is in place to choose different page sizes automatically.
Some embedded device makers with custom VFS layers use
this mechanism already.
Note that a page is the minimum unit of I/O for SQLite.
So increasing the page size from 1024 to 4096 means that
4 times as many bytes have to be written in order to make
a 1-byte change to a single record.
--
D. Richard Hipp <[EMAIL PROTECTED]>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
