LP1272316 - Speed up these settings lookups in the hold targeter that get repeated a ...

... lot when there are lots of copies for a hold.

Signed-off-by: Lebbeous Fogle-Weekley <lebbeous@esilibrary.com>
Signed-off-by: Mike Rylander <mrylander@gmail.com>
Signed-off-by: Chris Sharp <csharp@georgialibraries.org>
Signed-off-by: Ben Shum <bshum@biblio.org>
LP1272316 - Followup to make ou_ancestor_setting() even faster

Signed-off-by: Lebbeous Fogle-Weekley <lebbeous@esilibrary.com>
Signed-off-by: Mike Rylander <mrylander@gmail.com>
Signed-off-by: Chris Sharp <csharp@georgialibraries.org>
Signed-off-by: Ben Shum <bshum@biblio.org>
LP1272316 - Calculate proximity in the DB for speed

We need to calculate and store a (potenially adjusted) proxmity for
each hold and copy for use in targetting and optimization of op
capture.  Before this commit, we do that within the hold target
code itself.  Now we'll do it when the hold-copy map is inserted,
because we have the same information available at that time as we
have in the targeter.  This will both speed up the apparent cost of
the calculation, because it avoids the cost of a network round-trip,
and the total number of SELECTs we must issue, because the proximity
value will now be cached for use by the proximity map function.

Backward compatability is retained for the create_prox_map() function
in case any other code is depending on that.

Signed-off-by: Mike Rylander <mrylander@gmail.com>
Signed-off-by: Chris Sharp <csharp@georgialibraries.org>
Signed-off-by: Ben Shum <bshum@biblio.org>
LP1272316 - Stamping upgrade script for pre-calculate-prox-adjustment

Signed-off-by: Ben Shum <bshum@biblio.org>