Sadly, there's a modest cost to cold starting caches in Berkeley DB:

	[jbj@fedora10 wdj]$ sudo /usr/bin/time rpm -qa > /tmp/qa
	1.95user 3.98system 0:11.47elapsed 51%CPU (0avgtext+0avgdata 0maxresident)k
	1166552inputs+9248outputs (1018major+35645minor)pagefaults 0swaps
	[jbj@fedora10 wdj]$ sudo /usr/bin/time rpm -qa > /tmp/qa
	0.04user 0.37system 0:00.60elapsed 69%CPU (0avgtext+0avgdata 0maxresident)k
	11456inputs+96outputs (74major+31597minor)pagefaults 0swaps

The behavior is root-only as well, since only root can create the cache
in /var/lib/rpm. Non-root doesn't use a dbenv.

Which means that most lusers attempts to benchmark "rpm -qa" are going to be
flawed not only because of digest/signature overhead, and headerLoad() byte swabbing,
but also because the dominant paradigm everywhere is
	rm -f /var/lib/rpm/__db*

While I can easily crank the configgery screws down to cap the cache size, thereby shortening
the cold start cache prime overhead, teensy caches are obviously sub-optimal. Duh.

Note that the problem is gonna get worse when a dbenv is opened with
DB_RECOVER because the install log will be replayed to ensure ACID behavior.

(aside)
There's a vector I can stuff with a progress bar for DB_RECOVER, but
not for the cache priming (progress can be handled in many ways however).
Gak ... I loathe progress bars ... and RPM is a "batch" installer that
isn't supposed to spew by design.

Meanwhile its likely time to relearn to _NOT_ do
	rm -f /var/lib/rpm/__db*
unnecessarily.

Or take some valium and be happy!

73 de Jeff