Observed speed increases through judicious indexing
[working/Evergreen.git] / Open-ILS / src / sql / Pg / upgrade / XXXX.schema.general-indexing-needs.sql
1
2 -- No transaction needed. This can be run on a live, production server.
3 SELECT evergreen.upgrade_deps_block_check('XXXX', :eg_version);
4
5 -- On a heavily used system, user activity lookup is painful.  This is used
6 -- on the patron display in the staff client.
7 --
8 -- Measured speed increase: ~2s -> .01s
9 create index concurrently usr_activity_usr_idx on actor.usr_activity (usr);
10
11 -- Finding open holds, often as a subquery within larger hold-related logic,
12 -- can be sped up with the following.
13 --
14 -- Measured speed increase: ~3s -> .02s
15 create index concurrently hold_request_open_idx on action.hold_request (id) where cancel_time IS NULL AND fulfillment_time IS NULL;
16
17 -- Hold queue position is a particularly difficult thing to calculate
18 -- efficiently.  Recent changes in the query structure now allow some
19 -- optimization via indexing.  These do that.
20 --
21 -- Measured speed increase: ~6s -> ~0.4s
22 create index concurrently cp_available_by_circ_lib_idx on asset.copy (circ_lib) where status IN (0,7);
23 create index concurrently hold_request_current_copy_before_cap_idx on action.hold_request (current_copy) where capture_time IS NULL AND cancel_time IS NULL;
24
25 -- After heavy use, fetching EDI messages becomes time consuming.  The following
26 -- index addresses that for large-data environments.
27 -- 
28 -- Measured speed increase: ~3s -> .1s
29 create index concurrently edi_message_account_status_idx on acq.edi_message (account,status);
30
31 -- After heavy use, fetching POs becomes time consuming.  The following
32 -- index addresses that for large-data environments.
33 -- 
34 -- Measured speed increase: ~1.5s -> .1s
35 create index concurrently edi_message_po_idx on acq.edi_message (purchase_order);
36
37 -- Related to EDI messages, fetching of certain A/T events benefit from specific
38 -- indexing.  This index is more general than necessary for the observed query
39 -- but ends up speeding several other (already relatively fast) queries.
40 --
41 -- Measured speed increase: ~2s -> .06s
42 create index concurrently atev_def_state on action_trigger.event (event_def,state);
43
44 -- Retrieval of hold transit by hold id (for transit completion or cancelation)
45 -- is slow in some query formulations.
46 --
47 -- Measured speed increase: ~.5s -> .1s
48 create index concurrently hold_transit_copy_hold_idx on action.hold_transit_copy (hold);
49