Comment 3 for bug 874603

Revision history for this message
Dan Scott (denials) wrote :

Before we throw away case-insensitive search on the barcode column (someone must be using that somewhere, right?), let's dig into the history of this problem. It arose because we replaced the use of the native LOWER() function with the plperl evergreen.lowercase() function back in aa0ec9cba396a8b89322fc05a3c0664e16e69f2e - and as a result, the PostgreSQL planner assumes that the function will have an execution cost of 100 (vs. the native LOWER() function's cost of 1). The planner therefore ends up generating a bad plan, rather than relying on the index.

A much simpler fix, therefore, is simply to define a lower cost for this function:

-- For an existing database:
ALTER FUNCTION evergreen.lowercase(TEXT) COST 10;

Doing this resulted in sane results on our production database, versus the insane results that we saw with the default value.

If sites like Michigan with much larger patron databases than ours can reproduce this successfully, we can just add "COST 10" to the definition of the evergreen.lowercase() function and maintain case-insensitive search on the barcode column.