Re: Trust Packets

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Simon Josefsson <jas@xxxxxxxxxxx> writes:
>pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann) writes:
>> I've thought about this a bit in the past (I use databases to store
>> other types of keys) but because of the free-form association of
>> different bits and pieces of keys with identifying information I
>> can't think of any easy way to do it unless you use a multi-level
>> lookup.  That is, you can't do a:
>>
>>   SELECT key FROM table WHERE email = foo
>>
>> because there could be an arbitrary number of email addresses attached to a
>> key, and there could be an arbitrary number of keys associated with an email
>> address.  So you need something like:
>>
>>   SELECT keyID FROM indexTable WHERE email = foo
>>   SELECT key FROM sigKeyTable WHERE keyID = foo
>>
>> which isn't very efficient (multiple tables, multi-level lookups, etc etc).
>
>Have you tried this and found that performance is the most performance
>critical area?  

I hadn't really checked it, because the code could end up plugged into almost
any database type (via ODBC) on any kind of system, I wasn't sure that results
for one particular environment would be terribly useful.  For example if you
can tell the back-end (via SQL hinting) to use a hashed index held in RAM it'd
be pretty quick. If you end up with a linear scan on disk, it'd be pretty
awful.

>(The database contained the equivalent of ~2GB PGP keyrings worth of data,
>although the machine had enough memory to store the entire database in RAM.)

Yeah, well that would help a bit :-).

Peter.