Comment 23 for bug 635834

> But as you like plain numbers and I like my simple 'wall' clock experiments,
> lets dig a bit deeper here :).

I like KISS. The only issue with wall clock is that it is sometime difficult to analyze and compare
Otherwise I like wallclock a lot ...

> 1. pread() could be replaced with mmap()
Sure. But that's a deep change to uisng Berkeley DB, which has numerous consequences.
Likely better is just to use the existing mpool handling in BDB, with a
cache size appropriate for the data being cached, with double buffering
removed using O_DIRECT. But there's a balance that will be needed between
transactionally protected data and I/O performance, the balance can only
come with experience.

> 2. from time to time probably full copy of Packages file should be done
Easy to say but very hard to automate a ~100Mb copy with bullet-proofing.
Lusers need to design their own backups.

FYI: Packages (and the header blob within) are gonna be eliminated @rpm5.org
by the end of the year and replaced with mmap(2) onto a secondary store of /some/path/*.rpm.
The issue for trnsactional logging is reducing the size of the logs. But that
also means that all metadata must be stored in indices so that headerLoad()
is avoided.

> 3. hmm just wondering if using plain ASCII small files
Please do the math. Hash/btree access is _ALWAYS_ superior
to flat files for anything but toy in-memory cases. Or Oracle would not exist.

> 4. Wait till all users switch to SSD
Well NAND has its own I/O performance (and failure) issues, rather different than DASD. See
bz #529948 if you want to see s-l-o-o-w rpmdb perfomance.

> I think large DB files should be probably split to smaller pieces ...

Yup. Possible with db-4.8.24, not older versions.

> Anyway take this only just as my ideas - nothing you should probably worry
What me worry? ;-) All very sane suggestions, actively being implemented @rpm5.org.

E.g. signature/digest verification of header blob's (which are already PROT_READ
protected) was removed this morning.