![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
Is it possible to traverse a B-tree database (possibly in non-index order, with read-comiitted isolation) in a way such that most accesses happen in on-disk order? Due to internal fragmentation, whole-database scans are annoyingly slow once the database size exceeds available RAM. Would be using DB_RECNO or a sequence-based key a suitable workaround? |
#3
| |||
| |||
|
|
Is it possible to traverse a B-tree database (possibly in non-index order, with read-comiitted isolation) in a way such that most accesses happen in on-disk order? Due to internal fragmentation, whole-database scans are annoyingly slow once the database size exceeds available RAM. Would be using DB_RECNO or a sequence-based key a suitable workaround? What cache size are you using for the database? Default? |
#4
| |||
| |||
|
|
Is it possible to traverse a B-tree database (possibly in non-index order, with read-comiitted isolation) in a way such that most accesses happen in on-disk order? Due to internal fragmentation, whole-database scans are annoyingly slow once the database size exceeds available RAM. |
#5
| |||
| |||
|
|
On Feb 14, 1:24 am, Florian Weimer <f... (AT) deneb (DOT) enyo.de> wrote: Is it possible to traverse a B-tree database (possibly in non-index order, with read-comiitted isolation) in a way such that most accesses happen in on-disk order? Due to internal fragmentation, whole-database scans are annoyingly slow once the database size exceeds available RAM. How much of your database is located in overflow pages? |
#6
| |||
| |||
|
|
* Christopher Layne: Is it possible to traverse a B-tree database (possibly in non-index order, with read-comiitted isolation) in a way such that most accesses happen in on-disk order? Due to internal fragmentation, whole-database scans are annoyingly slow once the database size exceeds available RAM. Would be using DB_RECNO or a sequence-based key a suitable workaround? What cache size are you using for the database? Default? Uh-no, no, not quite. I've tried various values between 256 MB and 2.5 GB. And "db_dump -r" is acceptably fast (but plain db_dump isn't). |
![]() |
| Thread Tools | |
| Display Modes | |
| |