Question about --rebuild-keydb-caches
David Shaw
dshaw@jabberwocky.com
Sun Apr 20 22:20:02 2003
--mojUlQ0s9EVzWg2t
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Apr 20, 2003 at 12:57:53AM +0200, Ingo Kl=F6cker wrote:
[ rebuilding sig caches improves trustdb time by 75% ]
> My question is now whether there was a problem with my keyring (I have=20
> rebuild the caches several times since the days of 1.0.6) or is it=20
> always useful to run --rebuild-keydb-caches after larger changes in the=
=20
> keyring. In the latter case the documentation needs to be improved.=20
> Currently man gpg simply says:
>=20
> --rebuild-keydb-caches
> When updating from version 1.0.6 to 1.0.7 this command should be
> used to create signature caches in the keyring. It might be handy
> in other situ=ADations too.
>=20
> "other situations" could mean anything.
This is one of the little improvements that were rolled into 1.2.2.
1.2.2 is a lot more eager to cache signatures during --import so there
is less of a need to rebuild the cache periodically.
Still, there are some cases when signature caches are not created
automatically. For example, say Alice has signed Baker's key. You
import Baker's key, then Alice's. In this case, there is no cache
created as when Baker's key is imported, Alice's key is not yet
present to verify and cache the results of Alice's signature.
GnuPG is opportunistic in these cases and can add the signature cache
in the background the next time you --edit-key Baker's key.
There are a few other ways to improve performance here, but this is
unlikely to be in 1.2.3 (or any 1.2.x) as it would be a reasonably
large change.
David
--mojUlQ0s9EVzWg2t
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2rc2 (GNU/Linux)
Comment: http://www.jabberwocky.com/david/keys.asc
iD8DBQE+owEu4mZch0nhy8kRAohXAJ9QqmVXISRRWDnl+h0wb71agqJycQCghCBD
SX9n5MfqCHQqZnnRrf6z1IU=
=AfaR
-----END PGP SIGNATURE-----
--mojUlQ0s9EVzWg2t--