This directory contains three SQL scripts that control use of some new
code for planning/optimizing queries containing LIKE and
regular-expression operators. This code was added to Postgres 7.0 late in
beta test, and it hasn't gotten enough testing to warrant turning it on by
default in release 7.0 (although it probably will become default in 7.1).
So, here are some scripts to enable and disable it. You may want to run
these scripts if you have problems with the planner choosing bad plans for
queries involving LIKE or regexps in WHERE clauses.
HOW TO USE THE SCRIPTS
----------------------
All three scripts must be run as the Postgres superuser. The easiest
way to run an SQL script is
psql -f scriptfile databasename
or you can start psql interactively and enter
\i scriptfile
enablelike.sql enables use of the new planning code in the database in
which it is run. If you run it in template1, all subsequently-created
databases will use the new code by default.
disablelike.sql reverts to the old planning code for LIKE, in the database
in which it is run. If you run it in template1, all subsequently-created
databases will use the old code by default.
If your database was initdb'd with release 7.0beta5, you need to run
updatepgproc.sql before you can run enablelike.sql. Databases initdb'd
with 7.0RC1 or later already have pg_proc entries for the new code, so
updatepgproc.sql is unnecessary for them. If enablelike.sql produces
errors like "No procedure with name regexeqsel", then you need to run
updatepgproc.sql.
WHAT IT DOES
------------
These scripts install (or disable) new code for "selectivity estimation"
of LIKE and regexp operators. Selectivity estimation determines the
estimated number of rows produced by a query or subquery, and that in turn
determines the kind of plan the planner will use. The old selectivity
estimator ignored the pattern being searched for and just produced the
same estimate as for an "=" operator, which of course was usually too low
for a wildcard match. The new code has some knowledge of pattern matching
rules and generates an estimate based on the number of fixed characters and
wildcards present in the pattern. Also, if the pattern has a fixed prefix
that must be matched (such as LIKE 'foo%' or ~ '^foo'), an appropriate
range-query selectivity estimate is produced and factored into the result.
If you want to look at the code itself, see src/backend/utils/adt/selfuncs.c.
bfabd4f052