SQL optimizations (was RE: Successful LDAP signing test)

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Mon, 22 Feb 2010 10:35:49 -0800

> -----Original Message-----
> From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-
> bounce_at_lists.opendkim.org] On Behalf Of SM
> Sent: Monday, February 22, 2010 1:13 AM
> To: Mike Markley
> Cc: opendkim-dev_at_lists.opendkim.org
> Subject: Re: Successful LDAP signing test
>
> I think that the SigningTable/KeyTable could be
> optimized. Currently, we are running two queries. That could have
> been done in one query (JOIN) for SQL. That follows the KEY/VALUE
> concept discussed on the SigningTable thread.

That's certainly going to be easier on the SQL backend, but at some cost to the complexity of our code.

First, it will only work if the KeyTable and SigningTable are both SQL data sets on the same database. That should be easy to figure out or at least we can take a good guess based on the data sets' parameters.

Second, the higher layer of opendkim currently issues two "get" operations, and this is probably the right thing to do since we don't want those layers to have to know what's going on underneath (one could be a flat file, one could be SQL, and those layers shouldn't have to care). So if we decide a JOIN is possible, the first "get" would construct and execute the SELECT/JOIN and store the results, and the second would just reference the results of the first.

Is the optimization worth that complexity?
Received on Mon Feb 22 2010 - 18:35:57 PST