The size of the pages used in the underlying database can be specified as part of the db_open call to open the database, specifically by setting the the db_pagesize element of the DB_INFO structure.
The minimum page size is 512 bytes and the maximum page size is 64K bytes, and must be a power-of-two. If no page size is specified by the application, a page size is selected based on the underlying filesystem I/O block size. The selected size has a lower limit of 512 bytes and an upper limit of 16K bytes.
There are three issues to consider when selecting a pagesize:
First, the page size implicitly sets the size of an overflow record. Overflow records are either key or data items that cannot be place on a normal database page because of their size, and are therefore stored in overflow pages. Overflow pages are pages that exist outside of the normal database structure. For this reason, there is often a significant performance penalty associated with retrieving and/or modifying overflow records. Selecting a page size that is too small, and which causes a large number of overflow pages to be created, can seriously impact the performance of your application.
Second, Berkeley DB does page-level locking, i.e., access to records in the database is single-threaded at the granularity of a page, not at the granularity of a record on the page. Selecting a page size that is too large, and which causes threads or processes to wait unnecessarily because other threads of control are accessing or modifying records on the same page as the waiting thread of control needs to lock can impact the performance of your application.
Third, the page size specifies the granularity of I/O from the database to the operating system (i.e., Berkeley DB will give a page size unit of bytes to the operating system to be scheduled for writing to the disk). For most operating systems, there is an internal block size which is used as the granularity of I/O from the operating system to the disk. If the page size is smaller than the block size, the operating system may be forced to read block size bytes from the disk, copy the page size bytes into the buffer it read, and then write out block size bytes to the disk. (Obviously, it will be much more efficient for Berkeley DB to write page size bytes to the operating system and then the operating system to simply write the same page size bytes to the disk.) So, selecting a page size that is too small, and which causes the operating system to coalesce or otherwise manipulate Berkeley DB pages can impact the performance of your application. Alternatively, selecting a page size that is too large may cause Berkeley DB and the operating system to write more data than is strictly necessary.