Address the call number browsing performance problem raised in LP 690242
authordbs <dbs@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Wed, 15 Dec 2010 20:24:36 +0000 (20:24 +0000)
committerdbs <dbs@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Wed, 15 Dec 2010 20:24:36 +0000 (20:24 +0000)
commitbb918fa719e85f4f4d634387e8ae6d9358468403
tree514109c9af411c2f1f23e77f86faa9d41a33a7bf
parentb17e377b57a0e549d5bdb5c944234d1004e1f545
Address the call number browsing performance problem raised in LP 690242

The ORDER BY clause currently generated by call number browsing does not
have a sufficient index to use to assist the sorting of the returned rows,
and consequently does a sequential scan of the asset.call_number table.
Which, as you can imagine, is not fast for a system with more than a few
thousand call numbers.

This adds an index specifically to enable the query to go back to an
index scan instead of a sequential scan. We can investigate whether other
indexes should be removed to enable efficient data loading once we've
squashed the sequential scan problem.

git-svn-id: svn://svn.open-ils.org/ILS/branches/rel_2_0@19004 dcc99617-32d9-48b4-a31d-7c20da2025e4
Open-ILS/src/sql/Pg/002.schema.config.sql
Open-ILS/src/sql/Pg/040.schema.asset.sql
Open-ILS/src/sql/Pg/1.6.1-2.0-upgrade-db.sql
Open-ILS/src/sql/Pg/upgrade/0471.schema.asset-call-number-add-sortkey-compound-index.sql [new file with mode: 0644]