At 1/29/2002 11:20 AM -0800, you wrote: >This is not a Red Hat-specific issue, but there are some db-savvy >people in the peanut gallery. I'm hoping that someone with an >appreciation of database performance issues can tell me what kind of a >hit I'd be likely to suffer if I choose to store, index, and search >SSH public host keys (1024 bit) rather than their fingerprints (128 >bits) in a table. I'm currently working with MySQL, but would be >interested in how this might pan out in Postgres as well. I don't >have experience benchmarking this sort of thing. > >The issue for me is whether it's worth the overhead to convert the key >to a fingerprint before searching, or if I'm better off skipping that >step and just indexing the key itself.
Not expert, but been there. You're talking about a difference of about 100 bytes per key versus the overhead of more calculation. No answer is possible unless some other data is known, such as number of records in the database, number of searches or transactions per second, etc. If it's a small database, I'd go for the fingerprint; if it's fairly large, then studying the overhead versus the bulk is important. Don't know enough about tuning to help you, though; just know that whoever *can* help you is going to need more info. -- Rodolfo J. Paiz [EMAIL PROTECTED] _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
